Until recently, Apache Ant was seen as the default mechanism to do build-automation in Java projects. Since the Apache Maven project released Version 2 of their tool, it appears, that Maven has finally outrun Ant in popularity. This can be seen e.g, by observing other Apache projects, like Cocoon, that actually changed recently from Ant to Maven like many others. In this BLOG article I want to give some impressions of Maven 2 in comparison to Ant; and focus a little more in detail on dependency management.
Ant
Generally the concept between Apache Ant and Maven is significantly different. Ant can be seen rather like a toolbox, that offers a set of tools that can be used for developing a build process. This has advantages but also serious disadvantages.
The advantage of this concept is most probably it's flexibility. Many things can be done; the user is definitly not limited to "typical" development/build processes. I used e.g., Ant for some time to generate websites (offline) using XML and XSLT. Additionally as Ant was the dominating tool for the last years, it has substential tool support (e.g., Netbeans uses Ant build-files as default project file).
The advantage of this concept is most probably it's flexibility. Many things can be done; the user is definitly not limited to "typical" development/build processes. I used e.g., Ant for some time to generate websites (offline) using XML and XSLT. Additionally as Ant was the dominating tool for the last years, it has substential tool support (e.g., Netbeans uses Ant build-files as default project file).
However, in todays complex problems, the Ant approach has several drawbacks. What immediately comes to my mind:
- New users are often confuses what "best practices" should be used for a build process
- Reuse of Buildfiles is typically "Cut and Paste"; meaning: if you once spent a lot of time in fine-tuning a build file for a project it is difficult to use the same approach on a new project.
- As a consequence: different developers often have different approaches in writing build-files.
- Handling of libraries is awkward; we will come to that point later again.
Apache Maven actually has a very different approach towards the Software Build process. It is by definition not a toolbox, but follows the idea "Convention over Configuration". This means, that Maven is not only a build tool, but actually Build-Best-Practices implemented in Software.
Hence a complete build process including unit-testing can be started with one command and only minimal configuration in the so-called project object model XML file. But even a simple default project can be generated with one Maven command.
The consequences are clear: the beginner is not confused by many options and possibilities, but instead gets a clear route how to start; including directory and config filename defaults. This also has the positive consequence, that many Maven projects look very similar in structure, hence new developers have an easy time in getting into a new project.
Hence a complete build process including unit-testing can be started with one command and only minimal configuration in the so-called project object model XML file. But even a simple default project can be generated with one Maven command.
The consequences are clear: the beginner is not confused by many options and possibilities, but instead gets a clear route how to start; including directory and config filename defaults. This also has the positive consequence, that many Maven projects look very similar in structure, hence new developers have an easy time in getting into a new project.
Maven includes no only "build" jobs, but also performs unit-tests, code-quality checks and creates project documentation. If functionality is needed, that is not delivered "out-of-the-box" by Maven, additional plug-ins can be installed into the system.
Library (Dependency) Management
Maybe one of the most interesting functions in Maven is the management of dependencies. Up to now, managing dependencies typically meant to drop all required jars into a lib directory and add it to the classpath using Ant. However, after some time (and usage of systems like Hibernate) the lib directory was filled up with jars, and hardly anyone knew which of those are really needed in in which version!
Maven approaches this problem very differently: within the Project Object Model, the developer declares on which other systems this applications is dependent on including the version! E.g., coming back to Hibernate: In Maven you would declare a dependency to Hibernate Version 2.1.0 and Maven would figure out which additional dependencies exist (e.g., Hibernate might need dom4j and log4j and ...). This makes things much more transparent. Additionally Maven stores all libraries in on single directory (ordered by system, version, ...) and not within the project itself, which saves a lot of storage space, when multiple projects are developed on one system.
Maven approaches this problem very differently: within the Project Object Model, the developer declares on which other systems this applications is dependent on including the version! E.g., coming back to Hibernate: In Maven you would declare a dependency to Hibernate Version 2.1.0 and Maven would figure out which additional dependencies exist (e.g., Hibernate might need dom4j and log4j and ...). This makes things much more transparent. Additionally Maven stores all libraries in on single directory (ordered by system, version, ...) and not within the project itself, which saves a lot of storage space, when multiple projects are developed on one system.
Conclusion
From my point of view, Maven 2 is the next step in build-automation and will replace in the near future Ant in many if not most projects. It is true, that there are still some issues reported in larger projects using Maven 2, but these really appear not to be fundamental design flaws, but rather issues, that will be resolved with next minor versions.
However, my tip is to start a new Java project with Apache Maven 2; usage of Ant in new projects should have very well defined reasons. And unfamiliarity of developers with Maven is not a particularly good reason ;-)
References
I recently wrote a more comprehensive comparison between Apache Ant and Maven in infoweek.ch (german article).
Besides that, a lot of good information is meanwhile out in the Internet helping to get Maven 2 up and running: A good start is the Getting Started Guide from the Maven website. A more thorough coverage of Maven 2 can be found in the free Book from Mergere: Better builds with Maven.
No comments:
Post a Comment