Building with Ant and Ivy March 31, 2008Posted by Phill in General J2EE.
Tags: apache ant, apache ivy, dependency resolution, maven
At one of my previous workplaces we used to use Maven for our build system, along with Cruise Control. It was a pretty good system – Maven worked quite well and did all of our dependency management without any problems.
In case you haven’t heard about Maven before, let me quickly explain one of the key benefits of it: you define all the dependencies of a project in an XML file (pom.xml), and during the build process Maven will go and download all the required .jar files for you to use in the build. (Obviously, it caches them so it only downloads the ones you don’t already have!). This is a simplification (Maven can do more), but you get the gist.
If I was starting a “green fields” project, Maven would be a good choice.
Having said that, if you’re already using a project and want the benefits of dependency resolution, or you’re starting a new project and want dependency resolution along with the flexibility of Ant, let me introduce you to an Ant sub-project: Ivy. It’s also a dependency resolution framework, except that it runs from within the Ant build process. From my experimentations with it, it seems to run out-of-the-box with the Maven repository, and the dependency configuration is very similar.
But there are some very useful things Ivy has which Maven doesn’t, for example you can define a configuration for Oracle and a configuration for SQL Server, and the various .jar files will be included / excluded accordingly.
The Ivy project have a helpful comparison page listing some of the differences between Ivy and Maven 2.
There are a few downsides to dependency resolution, but I will hopefully cover those in a future article!
Building applications November 1, 2007Posted by Phill in General J2EE, Other Stuff.
Tags: apache ant, build, continuous integration, cruise control, maven
Unfortunately the scenario was all-too-familiar for me: in my first job as a developer, I was working for a small company. This meant that we were very busy, and little things like documentation were often missed (of course, this is something which bigger companies have been guilty of as well…) My development workstation became “The development machine”. This meant that when we needed to deploy an application, someone would come to me and say “Phill, we need a new EAR file for application x” (it wasn’t actually called ‘application x’, but actually that would have been kind of cool). I would then go into my IDE, open up the project, and run the build process.
The problem came when I needed to get someone else up to speed on the project… trying to get someone else’s IDE to be exactly the same as yours is a total nightmare. The dependencies were all over the place, it took hours to get it all up and running.