While it may seem a small thing, getting Guice 3.0 RC2 into Maven Central is actually quite a big deal. At this point Sonatype has been working well over a year to make this happen as it wasn’t just simply a matter of making some JARs and foisting them into Maven Central. Guice 3.x is now an integral part of Maven 3.x, Nexus, M2Eclipse and Sonatype’s Maven integration for Hudson so we care a great deal about the Guice ecosystem.
We started by providing patches to Guice for Maven 3.x and OSGi integration, working with the core committers to get our patches reviewed and vetted. At this point we only have a couple of patches (one for a deadlock fix in Nexus, and native injection of SLF4J loggers) that have not been integrated into Guice proper. Stuart McCulloch from Sonatype worked with Bob Lee, Jesse Wilson, Dhanji R. Prasanna and, now primarily, Sam Berlin from the Guice team to work in the patches in an acceptable way. We could have just forked Guice, and that probably would have been easier, but ultimately you can’t just go forking everything whenever you need a fix because eventually this become untenable. The surface area to support becomes unmanageable so spending the time and resources upfront pays for itself several times over fairly soon. The Guice guys are all perfectly reasonable: they want high quality, well thought out contributions and aren’t willing to take patches that work for limited use cases at the cost of the rest of the community. We appreciate that perspective and have no problems working within those confines.
While the patches were being integrated we also started looking at a Maven build for Guice. Sonatype has extensions for Guice, called Sisu, that allows the adaptation of any dependency injection system to Guice and so we initially needed a Maven-based way to build Guice and integrate our extensions so we could deploy them to a Maven repository for testing. Over time we started to Mavenize more of the Guice build and integrated the POMs the Guice user community created. The problem we were faced with was that the core Guice committers use Ant to build and they had no desire to use Maven in their day-to-day work. That was fine with us, we weren’t trying to jam Maven down anyone’s throat so we agreed that if we could make binary equivalent builds that the Maven build could be used to produce the artifacts that would be pushed to Maven Central.
This took quite a bit of work, review and patience but after making some adjustments and creating a couple new plugins we were able to make the Ant and Maven builds produce the same output. Along the way we made a new version of the Maven JarJar Plugin, which is now being used as part of the Maven-based Guice build, and updated the POMs to work with Sonatype’s Nexus OSS infrastructure so we can automate the release of Guice artifacts into Maven Central.
The final result is that we can now use Maven as part of the Guice release process to produce artifacts that satisfy the requirements of the Guice team and Maven Central. With the release of Guice 3.0 RC2 we have Guice itself along with all the standard Guice extensions available in Maven Central. Many thanks to the folks on the Guice team from Google, we know that Maven is not your first choice for build systems but appreciate you being accommodating and helping us create the process that gets Guice artifacts into Maven Central. Makes for a good day in the Guice community!