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.
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.
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.
Library (Dependency) Management
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.