Guice 3.0 RC2 is in Maven Central!

January 10, 2011 By Jason van Zyl

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][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][jarjar], 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][guice] itself along with all the standard [Guice extensions][guicee] 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!


  • Manfred Moser

    Thanks for all the hard work that has been put into this. This is very helpful for downstream projects depending on Guice allowing them to get into Maven central themselves now. It is also great that you took care of adding the no_aop version to central so that Android users of Guice can use it as well. Roboguice will be heading for central soon 😉

  • Dhanji R. Prasanna

    This is great news. The Guice team is very grateful for your patience and efforts. I think this will benefit the community in the long run enormously…

  • Stephen

    I publish both ant/ivy and buildr created jars+poms to maven repos all the time (using ssh/scp), so I’m not sure why you needed to go to all of the work of reverse engineering guice’s build system. Your comfort with maven aside, of course.

    • Stuart McCulloch

      There were several issues which we fixed by adding a proper Maven build – missing or broken dependencies, missing individual source bundles, missing individual javadoc bundles. While writing a script to take the Guice distro and repackage it for Maven Central would have been possible, it was about the same amount of effort to add the Maven poms – and the poms have other advantages, such as being able to load the project into Eclipse via m2eclipse.

      Ironically we also found some mistakes and discrepancies in the Ant build as part of this work, so it was definitely not wasted effort :)

  • Aigeec

    Great news guys, any chance of putting the actual dependency info up here :)

  • Gian Marco Gherardi

    i can’t understand why guice 3.0 RC2 doesn’t appear in search result of mvnrepository, mavensearch, javana etc..

    Is there a reason for that?