As I’ve mentioned in the past, I switched our company‘s build system from maven to ant. As part of this transition, we employed the Ivy dependency manager to handle the task of figuring out which libraries we actually needed to deploy with our system. In a previous post, I promised I would talk more about my experiences with Ivy. This post is quite overdue on that regard, but I doubt any of you were losing any sleep over it.
So, I had been delaying this post until I had officially made available my little contribution to the project: ivy+svn. Out-of-the-box, Ivy supports pulling down artifacts (typically jar files) and module descriptions (aka “ivy” files, similar to Maven’s POMs) from a variety of sources, including ibiblio.org, the filesystem, or any location expressible in a Java-resolvable URL. The ivy+svn plugin allows ivy to retrieve artifacts and module descriptions (aka “ivy” files) from a Subversion repository. So if you were pining for this functionality, pine no further.
I was going to use this post for apologetics about why one would even want to use a dependency manager with an SCM like Subversion. I’ve wasted enough bits and pixels defending this arrangement. Suffice it say, it works out quite well for our development team.
Instead, I’ll once again express my enthusiasm for the Ivy dependency manager. If you’re responsible for your project’s ant build, I recommend checking it out. And if you have any issues with it, don’t be afraid of the forums. The authors are very responsive and helpful. They’re also making great strides at extending Ivy’s funcitonality in creative ways. They themselves offer up useful additions to Ivy, including an Ivy UI tool for Eclipse and a “continuous integration” plugin for CruiseControl. They’ve also set up the IvyTools site for hosting 3rd-party open source plugins and extensions to Ivy, with ivy+svn being the first such tool.