As this recent blog post and subsequent discussion illustrates, the choice of build tool for Java projects can still provoke furious debate. As a long time user of both Maven and Ant, I’d like to think I have a good perspective on the various pros and cons of both of them. In fact, this perspective led to the creation of Kundo, an alternative open source build tool that sought to scratch both mine and others particular build management itches.
To use either Ant or Maven in anger you need a decent level of experience and understanding – particularly in the case of Maven. I’ve always viewed Maven as a ‘platform’ rather than a simple build tool as it aggregates/conflates a great many features. This means that the learning curve can be quite steep. I often encounter less experienced Java developers who wonder why working with these tools is so problematic – why do they need to contact the designated ‘build guy’ (or girl) when things don’t go according to plan?
More Data Than We Need?
Those who are familiar with the build tool domain will be aware of the ‘impedance mismatch’ that can occur between the metadata model used by Eclipse and that used by Ant, and especially Maven. In the case of Maven, this is because a POM file effectively needs to be the ‘master’ for project dependency metadata. Both the maven-eclipse-plugin and m2eclipse are good tools that seek to address this problem but I think its fair to say neither have yet completely eliminated the fundamental underlying issue. With Ant, the metadata synchronisation is simpler, but it still requires awareness from developers and they often have to be comfortable with Ant references and simple types to ensure changes in the IDE do not break the Ant build. Often Ant builds these days use either Ivy or the Maven Ant Tasks for dependency management anyway, so the problem can be much the same as with vanilla Maven in these types of projects. It is often not clear what the canonical metadata format should be and which tool ‘owns’ it.
Before I continue it is important to stress that I am focusing here solely on Eclipse, not alternatives such as NetBeans, IntelliJ etc that seek to address the problem in different ways.
Part of our mission with Mike is to lower the barrier of entry to using Continuous Integration (CI), so we have sought to include features that mean you don’t need to be a build tool guru to use our platform. Our ‘Eclipse build’ feature is a great example of this. It allows developers to simply add an Eclipse project to our hosted CI service without the need for an associated build.xml or pom.xml file. Then, at build time, Mike parses the project metadata and uses this within a vanilla life-cycle that processes resources, compiles production and test code, runs JUnit tests and creates an appropriate artefact. There are some constraints and conventions that need to be applied with this approach – at the time of writing the feature only supports the Dynamic Web project type using Apache Tomcat 5.5 or 6.0 runtimes – but here at Mike HQ we feel it allows you to be up and running with CI in very short order and we will be seeking to extend the range of project types, natures, builders etc that are supported. Of course, should you wish to subsequently own greater control over your CI build you can always add the appropriate Ant or Maven configuration at a later date and Mike will build that too.
From a pure CI perspective, this may seem to contravene the suggested approach in Martin Fowler’s original article – specifically the statement about IDE data being ‘fragile’. However, if all your developers are using a standardised version of Eclipse and apply a sensible approach to modifying the state of a project, many of the supposed issues can be avoided.
Aside from the Maven-specific tools mentioned above, it’s only fair to point out that there are other open source initiatives and projects that seek to address this same problem. In Kundo we sought to provide a ‘pluggable’ dependency management solution with one option allowing the use of Eclipse metadata as the source of your binary dependency locations. For this feature Kundo delegates to ant4eclipse. The aim of the ant4eclipse project is to avoid (or at least to reduce) the redundancy of Eclipse and Ant configurations and it consists of Ant tasks that are able to parse Eclipse metadata. More recently, the headlesseclipse project has emerged which seeks to solve the same problem by using the built-in AntRunner of Eclipse.
Finally, there is the B3 project proposal from the Eclipse community itself which, in their own words, has a goal to “develop a new generation of Eclipse technology to simplify software build and assembly”. I will be closely watching that proposal with interest to see if it finally addresses the build management metadata redundancy/synchronisation issue with Eclipse.
Tags: Ant, ant4eclipse, build, continuous integration, Eclipse, m2eclipse, Maven
Mike CI blogs 
Leave a comment