Maven to be Built on Guice

Posted by Josh Long on Feb 04, 2010

Sections

Process & Practices,

Development,

Operations & Infrastructure

Topics

Java ,

Build systems ,

Artifacts & Tools

Tags

Maven ,

Guice

Update February 5, 2010, 23:15 GMT: The initial version of this post errantly explained that Maven 3 will be built on Guice. It has been brought to our attention that, while work is planned to ultimately move Maven to work on top of Guice, there is no committment for the 3.0 version, per se. Our apologies for any confusion, and thanks to Jason van Zyl for clarifying the situation with Maven 3.

Sonatype, the professional services company that sponsors the development of many key Maven committers, has announced that they are investigating moving Maven to a plugin layer on top of the Guice Dependency Injection (DI) container, and moving away from the Plexus DI container. The decision to use Guice was apparently not made lightly. Plexus, an aging DI container, has been used in all versions of Maven. It was used originally - as Jason van Zyl (the Maven project and Sonatype founder) describes - because it was one of the only viable options when Maven 1.0 was conceived. Avalon, a now defunct Apache project, was one of the well known, alternative, DI solutions.

Maven is a build tool that prescribes convention-over-configuration based heuristics for building an application. It has seen some fanfare for its utility, though many have bemoaned its seeming inflexibility. To adapt Maven to a task you can configure an existing plugin - which is a pretty painless task - or write your own. Many developers suffer here. Plexus is used internally in the Maven runtime by the plugins. Plugin authors need to understand Plexus - often a tedious undertaking because the Plexus documentation is poor - to write custom Maven plugins or to better understand existing ones. van Zyl cites many reasons for the proposed migration from Plexus to Guice, besides the poor documentation. He describes the need to reduce the commitment to the Plexus project, saying that the Maven project didn't intended to build and support a DI container, but to promote and build tools and infrastructure supporting developers and builds.

Meanwhile, another project surrounding Maven, called Polyglot Maven, promises many other enhancements to make writing plugins and adapting Maven easier, including support for Maven pom files written in other languages (like Groovy, or Scala, for example.)

Guice is a popular DI container originally developed by Google staffers - including Bob Lee. It allows implementation classes to be programmatically bound to an interface. Then, the resulting instance may be injected into constructors, methods, or fields using the Guice @Inject annotation.

More recently, Guice has added support for JSR 330. JSR 330 specifies a portable, useful subset of DI functionality which may be implemented across different implementations. Support is already available in many implementations, including Guice and SpringSource's Spring Framework. Both Bob Lee and Jason van Zyl were on the JSR 330 team. Maven's Guice support will be written using the JSR 330 annotations, so that future portability - if required - isn't an issue. In order to ensure a smooth migration from Plexus to Guice, a bridge layer will be built using Guice. Guice was the only container they tested that was up to the task of facilitating a bridge from Plexus, which made the ultimate choice easy.

Guice provides other compelling features as well: peaberry support (peaberry is an extension module on top of Guice that supports resolution and injection of dynamic OSGi-based services), type safety, and useful error messages. While some of these are not unique to Guice, they do make it a compelling alternative. The Maven team has still had to support a patched version of Guice to meet their requirements. Most of these, says van Zyl, are being contributed back or made available. The ones that haven't yet been contributed are either insignificant or are still being tested and verified.

Initial work on integrating Guice is already afoot on other projects (like the popular Nexus server, Tycho, etc.), and will flow through the various Sonatype projects before it ultimately makes its way into Maven itself.

1. Back to top

   But not immediately

   by Brett Porter

   I think you've read too much into Jason's post.
   
   While Sonatype seem to be moving their products over to Guice now, changes are not on the Maven development roadmap for 3.0 at all. Consider the response at the top of this: markmail.org/message/4w46ioimp4vrssx3.
   
   While it's likely the direction we'll take, work on 3.1 is not going to happen until 3.0 is done. I look forward to seeing Guice in place, but the amount of work and testing it is going to require for existing plugins is not insignificant, and we need to ship the existing improvements.
   
   Likewise, Maven 3.0 will not contain support for other POM formats out of the box at this stage, and other languages are unlikely to make it into the core distribution - the work you describe is another external project.

   Reply

2. Back to top

   Re: But not immediately

   by Josh Long

   Brett, thanks for the correction. We're certainly seeking clarification and will amend the post as we can.
   
   Maven 3 looks very interesting, though I - as a developer - was certainly looking forward to having a much Guicier, approachable plug-in API, too! :-)

   Reply

3. Back to top

   Title and content not quite accurate ...

   by Jason van Zyl

   We're not dropping support for the use of Plexus. One of the primary reasons for using Guice is that we are able to support the use of Plexus components for as long as we need to while allowing new constructs to be used. Support for running Plexus components is likely to span many years. We have what we call a Plexus/Guice shim which adapts the Plexus form of components we have to run transparently within Guice. We are going to encourage folks to use JSR 330 constructs for DI, but we're certainly not dropping support for Plexus.
   
   The support for different POM formats and DSLs is part of the Sonatype project we're calling Polyglot Maven which you can find here:
   
   polyglot.sonatype.org
   
   The use of Guice within Sonatype's own open source and commercial projects is working faster then we expected. It's an integration we work on daily, so if it happens to accelerate even faster there is a small chance it may make it into Maven 3.0. Stuart McCulloch, who is responsible for the integration, works very quickly! :-)
   
   Sonatype primarily cares about the compatibility, stability, and the performance of Maven 3.0 and that's what we've been focusing on. We can tell immediately whether a change causes problems and if we can make some of the last few changes in the Guice integration in time then it might be something we can do. For the change flows through a chain of tools that also have to work. For us that's M2Eclipse (m2eclipse.sonatype.org), Tycho (tycho.sonatype.org), and Nexus (nexus.sonatype.org). When those all work then it's pretty much a go for us on the Maven side.
   
   Jason van Zyl

   Reply

4. Back to top

   Re: Title and content not quite accurate ...

   by Ryan Slobojan

   Hi Jason,
   
   Thanks for the clarifications - we've updated the article above based on your comments.
   
   Ryan Slobojan
   Chief Editor, InfoQ.com

   Reply

• Older >