I have had the good fortune to work on many software development teams over my career, and I believe this has contributed to my interest in creating effective development environments. Each time I started a new project, it seemed like I would spend a couple of days copying the best ideas from the previous project and reworking the problem areas, hopefully creating a much cleaner and simpler environment. This first step was concerned with the basic build environment, putting the ant scripts, dependent libraries, and Cruise Control into place. Unfortunately, this exercise usually consisted of a lot of cut and paste activities…
I can’t tell you how many times I have setup projects, implementing the Ant tasks for Cruise Control, PMD, Checkstyle, Clover, JavaDoc, etc… The fact that my Ant scripts were never really reusable always bothered me, but each project was independent and reuse at the corporate level never seems to pan out, so all I could do was cut and paste. Jar file management was also painful, as each project generally manged these resources in a unique fashion. I always tired to standardize my projects with a lib directory, which contained a sub-directory for each product. This sub-directory would usually include the version number in the name, so we had some idea of what version was being used. Most projects were a little more free form, they just dumped all of the jars into a lib directory with no concern for managing the component version information. Larger projects tried to create common SV
N module, just for their jars, but this was not the norm.
N module, just for their jars, but this was not the norm.Enough history. I had done a lot of reading about Maven, but never took the plunge. The Maven philosophy was very different from what our teams were used to, but I was really intrigued by the dependency management aspect. This lead me to Ivy. Ivy was created to address a single problem, dependency management. Ivy was much easier to integrate into our existing environment, plugging into both Ant and Eclipse.
Ivy allows me to document, one time, all of the relationships between the open-source products in our environment. Once documented, these dependencies can be reused by all projects. Each team is no longer required to manage all of the open source jars and their dependencies, they can delegate that responsibility to Ivy. There are numerous other subtle benefits too, our code repositories are much smaller (jar files not checked in multiple times), the exact versions of each open-source product used was documented in the project it was used (project level ivy.xml files), better control over unapproved software (software must be approved before it is promoted), and it can even manage, tie together, the source code, Java documentation, and supporting files (license, css, tld, etc.).
One of the more interesting challenges was defining a strategy for integrating Ivy into the build process of large organization. Because we had multiple groups responsible for different stages of the process, we decided on a multi-repository strategy. Developers would have full access to the Sandbox repository, to install and configure new Ivy modules. Once the Sandbox modules had been tested and validated, they could be individually promoted to the External repository. The External repository is for any component, open-source or corporate, not built by our organization. The Internal repository is used to publish reusable components created by our organization. Ultimately, modules from the External and Internal repositories can be promoted to the Live repository, to be utilized by the production build process. As modules are promoted or retired from the Live repository, a baseline tag (and corresponding ivysettings.xml file) is created to capture the state of the repository. It is this tag (SVN URL) that is provided to the development teams. When each application’s schedule permits, the development teams can migrate to the most recent baseline of the Live repository.
I am completely sold on Ivy and use it for all of my home experiments; I feel it is much easier to mange an Ivy repository, than copy jar files from project to project. All I need to do is add a simple ivy.xml file and my project is ready to go. Setting up Ivy in corporate environment is a little harder, it is more about the process than what the tool actually does.
