Arrested for not using a build tool!!
Do you use a build framework? Which build framework do you use? Is your build framework open-source, commercial or even custom? Ant, Maven and Gradle are three open-source build frameworks that I plan to use in a build experiment.
The experiment is intended to be the first of many set around the build process. Future planned experiments include the integration of these frameworks with repository managers, continuous build integration, static code analysis/error detection and reporting capabilities to determine technical debt.
The Experiement
I intend to create a simple build using each of these frameworks. Each build is required to:
- Use JUnit 4.8.2
- The latest version of OpenPojo (used in the small application to test)
- The build framework is the only requirement to perform the build in a Java environment
- Dependencies should be retrieved or bootstrapped when required
Once each of the builds has been created I intend to compare them. Comparisons should provide useful feedback for the builds in this context. Current comparisons I am considering involve comparison of:
- Implementation time and complexity
- Dependency management flexibility
- The ability to tailor the build configuration
The Frameworks
I have been using Ant as part of my Java development for as long as I can remember. Having hand crafted numerous build files using Ant’s verbose XML syntax and extended Ant via custom tasks, it is my staple build framework of choice. I enjoy the flexibility it provides and the ability it offers to tailor builds to meet specific requirements.
For this experiment I am conscious that Ant will require the bootstrapping of Apache Ivy to enable dependency management. This means there will be added complexity from the start for the Ant build. This added complexity though is tempered by the flexibility Ant will offer me to perform the other tasks.
Maven [Maven Website]
I have experience using Maven but have not yet been convinced it is worthy of replacing Ant in my build processes. Maven 1.0 and 2.0 had failed to convince me that I should ditch Ant just yet, maybe Maven 3.0 will change that! When working with Maven I have encountered the need to revert back to Ant for certain unorthodox build steps. Maven does appear to have some flexibility issues, and I have been privy to several discussions around these issues. I do believe the tool does have benefits, such as its dependency management, and have included it in this experiment as a chance for Maven to demonstrate that it has what it takes to be considered as my build tool of choice.
Most of my Maven experience has involved the maintenance of and the addition of functionality to existing pom files rather than building the pom from scratch. The Maven build should prove simple to implement unless the specific JUnit version requirement causes the test phase of the build issues. I am hoping Maven can pleasantly surprise me with its simplicity to meet the experiment requirements.
Gradle [Gradle Website]
Gradle is the new kid on the build framework block. Having recently built a Grails application and delved into the world of Groovy I am eager to see if this framework can compete with the more established Ant and Maven. Will it prove to have the flexibility of Ant enhanced by a Groovy script implementation along with dependency management comparable to that of Maven?
I have not even download Gradle yet! Some time ago I intended to look at GAnt as an Ant alternative. GAnt is not a build framework. It enables Ant builds to be built using the Groovy syntax rather than using the Ant verbose XML equivalent. Gradle uses Apache Ivy for dependency management (as the Ant build will do). Having experienced the increased efficiency Groovy can provide utilizing the power of Groovy scripts in the build process is very appealing to me.
The Expectations
I believe Ant whilst offering the most flexibility will prove to be the most complex of the builds largely due to the need to bootstrap dependency management and its verbose XML syntax.
Maven has excellent dependency management built in but the requirement to use a specific version of JUnit may cause issues with the built in test phase?
If Gradle does provide the flexibility of Ant along with dependency management comparable to that of Maven combined with a Groovy scripting nature it could prove to be my build tool of the future.
I am interested in hearing about alternative build frameworks worthy of investigation, as well as build experiences relevant to this experiment. I would also be interested in ideas to extend this experiment that would provide more realistic project comparisons – really pushing the framework limits etc.
I will be storing the build scripts on GitHub and will post the link once the first implementation has been committed.
If you use ivy with ant, you can have an excellent dependency management.
Why do you think that Maven requires a specific version of Junit? You can use any version you wish.
It going to be interesting to see your results. But I guess its all a matter of opinion.
@Dave: I know you can use a specific version of JUnit with Maven, but when running the test phase does it use a pre-determined version or a specified version. – A mentioned I have mainly maintained pom files, rather than written them – I am hoping increased understanding of the Maven build phases and set up will be part of what I will gain from the experiment.
@redsolo: I agree it will be interesting to see the results, and of course at the end of the day I will post my opinions but am hoping those opinions will raise some discussion.
Hi Peter,
@Dave is correct – Maven will use whatever version of JUnit you specify in your pom file. But at the time of writing, I don’t think junit 4.8.2 has been published to the public repositories yet (4.8.1 is the latest version on repo1). That’s nothing to do with Maven, though
i have just a littel experience about ant, i never see maven in action, but i know the importance of a build framework in my job. i will follow this your experiment with a lot of interest!
Last JavaEdge conference I made a session comparing different build tools (much more than Ant, Maven and Gradle). Take a look on it – http://prezi.com/ngwwf1wcfn7n/
Don’t forget Buildr (buildr.apache.org)
Yes please try Buildr too. It would make this a very complete assessment. It’s a damn shame that so many projects, are not publishing to Maven central. That hurts Ivy, Gradle and Buildr just as much as Maven.
For Maven you shouldn’t have to do more than this:
mvn archetype:generate (choose quickstart)
cd project-name
Change Junit version to the latest in pom.xml (jarvana.com for this)
mkdir lib
cp $downloads/openpojo.jar lib/
Add java 1.5 to the build (pet peeve, I hate java 1.4 as default: http://blog.cliffano.com/2007/07/10/going-java-15-with-maven2-based-project/)
Add this to pomfile (I also hate projects not in central):
I am a project that doesn’t publish to central
Therefore-I-can-put whatever-I-want-here
1234567
system
lib/openpojo.jar
Fantastic. It stripped my XML tags, just imagine this around the bottom part.
[dependency]
[groupId]I am a project that doesn’t publish to central[/groupId]
[artifactId]Therefore-I-can-put whatever-I-want-here[/artifactId]
[version]1234567[/version]
[scope]system[/scope]
[path]lib/openpojo.jar[/path]
[/dependency]
Of course the best way to do it is to install the jarfile into your repo, very easy if you are using Nexus.
@Baruch – thanks for that, will take a look at your presentation.
@John – that was what I meant by being unsure if I would have problems with the test phase using 4.8.2 – as with it not being in the Maven repository what do I need to do to include it. Yes I agree this is not a fault with Maven, but if I need to use that version is it simpler to do it with Maven or Ant etc.
@Mark & Jospeh – I will take a look at buildr, and based on that and Baruch’s presentation maybe extend this experiment.
@Peter – I am curious to know the outcome of the experiment as well, and how OpenPojo worked for you
.