We have a monolithic code base. It is something you end up with if you keep adding classes, without thought to larger modules. So how to solve the problem. Break the code up into modules. Also figure out how to combine these into applications. Then look at whether to run these together in the one JVM or separately.
One problem that comes up is tool support. Ant on its own does provide ready made solutions to this.
We needed a higher level build system on top of Ant that provides a default means of dependency management, multi-project relationships, and generation of build artifacts such as jars, wars, and ears.
A look around shows a number of approaches: Ant + Ivy, Maven, Ant + Antlib for Maven and Maven + antrun plugin.
Maven is a popular and widely used build system which handles dependency management and multi-project relationships. It operates at a higher level than ant, sort of like what Hibernate is to JDBC. Maven scripts tend to be much shorter than Ant scripts to get an amount of work done.
- a dependency management system. no more ?lib/*.jar? dependencies
- a standard for an artifact repository that handles packages and version numbers, javadocs and source code (of releases), either centralised or proxied.
- a ?standard? project lifecycle where you can ?plug? special processing. All projects go through: generate source, compile, package, install etc?
- Simple project setup that follows best practices – get a new project or module started in seconds
- Consistent usage across all projects means no ramp up time for new developers coming onto a project
- Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
- Able to easily work with multiple projects at the same time
- A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for real-time availability of their latest releases
- Extensible, with the ability to easily write plugins in Java or scripting languages
- Instant access to new features with little or no extra configuration
- Ant tasks for dependency management and deployment outside of Maven
- Model based builds: Maven is able to build any number of projects into predefined output types such as a JAR, WAR, or distribution based on metadata about the project, without the need to do any scripting in most cases.
- Coherent site of project information: Using the same metadata as for the build process, Maven is able to generate a web site or PDF including any documentation you care to add, and adds to that standard reports about the state of development of the project. Examples of this information can be seen at the bottom of the left-hand navigation of this site under the “Project Information” and “Project Reports” submenus.
- Release management and distribution publication: Without much additional configuration, Maven will integrate with your source control system such as CVS and manage the release of a project based on a certain tag. It can also publish this to a distribution location for use by other projects. Maven is able to publish individual outputs such as a JAR, an archive including other dependencies and documentation, or as a source distribution.
- Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project’s clients can use to download any JARs required for building your project from a central JAR repository much like Perl’s CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with. We are collaborating with the folks at Ibiblio who have graciously allowed the central repository to live on their servers.
Potential Issues with Maven
The historic issues with Maven and the current status are:
- Maven was poorly documented. This has been improved somewhat, particularly with a freely downloadable PDF book on Maven2.
- Is their a critical mass out there? There now is. It is becoming very common to see pom.xml’s in projects. pom.xml comes up on Google in a 1:4 ratio with Ant. So it has critical mass and is not going away. Ibiblio has a very large number of projects in its repository.
- The changeover from Maven 1 to Maven 2 was untidy and confusing. Now everyone is one maven 2
- Maven has an initial learning curve. You need to dive into black magic to develop a maven plugin when you need to do custom things and this is hard. You can always call into an ant script. Developing a plugin is optional.
- The central repository may not be available. The solution is to use a local repository. See http://cocoon.zones.apache.org/daisy/documentation/g1/1164.html
Ant + Antlib for Maven
Maven 2.0 now comes with a set of Ant tasks that can be used to utilise Maven’s artifact handling features from within Ant. Included are:
- Dependency management – including transitive dependencies, scope recognition and SNAPSHOT handling
- Artifact deployment – file and SSH based deployment to a Maven repository
- POM processing – for reading a Maven 2.0 pom.xml file
Remaining Problems with Ant
Ant files tend to become huge. Can be solved, as of ant1.6, by the ant import nd macrodef tasks.
Each project ends up with duplicated Ant code. Can be solved, as of ant1.6, by the ant import nd macrodef tasks, although you then need a common artifact
No standardised build structure. This can be enforced manually.
Ant + Ivy
Ivy works very much like Ant + Maven Antlib. It has arguably a better dependency management process. It does not have a central repository of projects. You have to package third party stuff up and put it in your Ivy repository. It does not provide the extra features of Maven beyond dependency management.
Making a Choice
In terms of what projects are using, one way to tell is to search google for the config files that are used by each tool.
A google search for build.xml returns 3,240,000 results.
A google search for pom.xml returns 786,000 results.
A google search for ivy.xml returns 17,900 results.
Both Ant and Maven are mainstream. Ivy is a niche player by this measure.
Matt Raible was an eager Ivy user, then moved to Ant + Maven Antlib then moved to Maven as of September 06.
The Spring project is moving to Maven.
Much of CodeHaus and Apache have/are moving to Maven.
I know people who use Maven and those that use Ivy. Both Maven and Ivy are part of Apache.
The Maven project is extremely poor at fixing bugs and getting releases out. Ivy has a better reputation.
Summing UpIf you are an open source project, the chances are that you need to publish your releases to the Maven central repository anyway. This requires you to have a Project Object Model (pom.xml). In your pom.xml you need to specify your dependencies. It is not that much more work to simply delete your lib directory and plug in the Maven Antlib to your ant build. This is what I have done with ehcache and jpam, two of my open source projects. If you are an open source project Ant +Maven Antlib seems a safe choice.
I have not made the move to pure Maven because I think it would take a fair bit of work. I have started to do so then run into limitations or bugs. The large numbers of unresolved bugs trouble me greatly.
If you are doing Corporate development, like using Ant and have existing projects you want to solve the dependency management problem for, I would say go either with Ant + Maven Antlib or Ant + Ivy.
At work we opted to go pure Maven and convert our existing Ant projects. I am not sure at this point that it has been worth it.