A few days back I noted how Apache Shindig is disconnected from the Apache Portals project. Janus Boyce of CMSWatch has opined that this is exactly how Apache functions - innovative but disconnected.
Recently I came across the Apache Ivy project which seems to reinforce this sentiment. Apache Ivy is a dependency management framework tightly integrated with Apache Ant, the build tool. And if you use Ant + Ivy you get most of the stuff that can be done by Apache Maven, the software project management tool.
While the Ivy project developers make a fair argument, it is true that there is a whole lot of redundancy across Apache projects that needs to be fixed lest it leads to confusion and fragmented developer communities.
Saturday, December 29, 2007
Ant + Ivy = Maven ?
Subscribe to:
Post Comments (Atom)
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
8 comments:
Many people think that magic in the integration build should be kept to a minimum. Ant scripts show what is being done, but maven does not. I don't like the amount of CoC that has been bundled into the maven environment (too much reading to get something done), and I don't think the 90-10 rule is correctly applied in maven. When you need something that breaks The Maven Way the amount of extra work makes it not really worth it.
That being said, I don't really like ivy either. Right now I am using maven ant tasks to resolve dependencies and it seems to cut it better than ivy.
Ignacio,
I have a different point of view. I don't mind the magic in the build scripts as long as I understand what that magic is. But as you rightly put, the more you deviate from "The Maven Way" of doing things, the worse you are.
I currently use Maven. But fortunately I am not doing anything different from the standard functionality. There are a few nits and I have addressed it by using the Maven AntRun plugin and using ant tasks inside my build script :-)
I think if you look at the entire scope of what Maven brings to the table you can see that Ant+Ivy != Maven.
I agree with the previous poster. Ant+Ivy != Maven, because Ant+Ivy is by far more superior. Maven is good as long as you follow the Maven way. But just try to create a build environment that is not quick-and-dirty and more professional (let's say with a serious staging model (development,integration,qs,prductive for example) and recreatable builds (this includes the used dependency versions for a build). Easy with Ivy, the hell with maven...
Maven 2 (not Maven 1, because that was a prototype that made it into production) is a lot more then ant+ivy.
However, the best thing it did for us, is standardizing the build lifecycle (although you can easily customize it if you know how).
If an open source project uses maven 2, I do the effort to provide patches, otherwise I don't. Why?
I can check it out, build it (="mvn install"), run the test cases, generate the eclipse/IntelliJ/netbeans config, fix my issue, create a patch and send it back to the project... without spending hours figuring out how the ant files work, how to configure my IntelliJ, where the source files are, ...
Although I've never really used Maven neither Ivy, I think (by all the reading) both are different products that overlap in a very visible feature: dependency management.
In Ivy, this is the main feature, in Maven not. So the confusion arises.
The post title is a question about how this feature overlap affects both products as an effort division, not about the products themselves.
Even though comparing Ant+Ivy and Maven 2 comes out very often, you really can't say that Ant+Ivy = Maven.
Both tools can be used to achieve very similar purpose, but in very different ways: with Maven you describe your project and let the tool drive your build, with Ant+Ivy you describe your build process with the help of the tools to deal with hard problems like dependency management and build reproducibility.
IMO Ant+Ivy biggest selling point is flexibility, while Maven's one is out of the box experience and conventions.
But competition is good, even within the Apache Software Foundation. Even more competition in the web framework area is already happening in the ASF, and even more competition in the build area is coming with buildr being an ASF incubating project. That will force projects work on innovation and let users choose the right tool for their use.
I use ant + ivy + a set of importable ant build files that reproduce part of the maven process. I wonder if this set of importable build files already exists as a project somewhere or whether someone is interested in making this a project.
For example, I make a java project by putting my code in src/main/java and src/test/java. I create an ivy.xml file and a build.xml file. build.xml is about 3 lines long. It just imports java.xml (which is common to all my java projects). java.xml defines targets like "clean, compile, test, jar, package, publish". It also defines classpaths that I can use in build.xml to run java processes with my code.
If I need something specific to the project, I add it in build.xml.
This way I get: 1) The robustness and maturity of ant. 2) Integrated dependency management with ivy. 3) Standardization with maven-like conventions.
I struggled with maven for about a year and abandoned it, but kept much of the maven process and conventions, which I think are valuable on their own.
Alexandros A.
Post a Comment