What does this mean for you as an end-user?

Guice is emerging as a lightweight Dependency Injection standard. We’ve moved the core of Maven to Guice over the past two years and it has dramatically increased performance and opened up possibility for integration with other tools and libraries. Since Guice is implementing JSR-330 standards, what we’re really doing with this effort is moving Hudson to a more standard, more maintainable architecture. As an end-user, you will likely notice increased stability as the core becomes more modular, easier to maintain and test. You should also expect greater integration with other tools that can speak the JSR-330 standard. This includes components that use both Guice and the Spring Framework.

Our Plan for JSR-330 Integration Going Forward

We’ve been working on decoupling both our JSR-330 and JAXRS work from our commercial version of Hudson for a couple of months. Our current focus is to allow Hudson plugins to take advantage of the JSR-330 Dependency Injection standard and then work toward using JSR-330, via Guice, in the core of Hudson itself. We have opened the Github repository containing the Hudson JSR-330 work which also contains a small example of a [Hudson Plugin written using JSR-330].

We’ve been using this new Hudson JSR-330 mechanism to create our JAX-RS (RESTful Web) integration, and our Maven 3.x integration. We will be working as fast as we can to propose and deliver our JSR-330 integration, JAX-RS integration, and our Maven 3.x integration back to the Hudson Community. Stuart McCulloch, who has been working on our Guice strategy, will be doing this work and following up with proposals on the Hudson Development list. Jeanfrancois Arcand is working on a REST framework, based on Jersey, that we will be proposing for integration into Hudson which is how we see webservices working in Hudson going forward.

Our GWT-based UI for our Maven integration relies upon these REST services, and our GWT-based Maven 3.x builder also uses JAX-RS as a communication channel back to the server. While it is unlikely that we will be able to stop using Jelly completely in the near future, this work will set the stage for a Hudson that is based entirely on RESTful web services. This isn’t easy work, we’re trying to set the foundation for future UI while maintaining compatibility for plugins that continue to use Jelly. Jeanfrancois is also looking at the integration of Atmosphere to make the standard pages in Hudson more efficient with respect to communication to the server.

So this is just the start of what we said we would deliver. More pieces will be released as they are ready. If you are interested, please take a look at the JSR-330 integration work we’ve done and look forward to more posts about JSR330 next week! If you have any feedback, please provide your comments or email questions. We’re excited about the work that has been done and the work yet to come.

Maven Stack Infrastructure

I’m going to talk about some of the under pinnings of the technologies we’re using as part of our Maven work. Why we selected the technologes and some of the current work that’s happening.

• Guice
• From Plexus to Guice (#1): Why Guice?
• From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
• From Plexus to Guice (#3): Creating a Guice Bean Extension Layer
• Peaberry
• Apache Shiro
• Enunciate

Maven

There are several develops going on in the various Maven projects. Maven 3.x is on the way, but we have some very interesting work happing with OSGi within our Tycho project. The Flexmojos project and NAR (the C/++ framework for Maven) are also popular.

Tycho

• Tycho Site
• Tycho @ Github
• Tycho/PDE Integration
• P2 Site

Flexmojos

• Flexmojos Site

NAR

• NAR Site
• NAR @ Github

M2Eclipse

The primary IDE integration we work on at Sonatype. The most important thing to talk about in M2Eclipse is the configuration framework.

• M2Eclipse Site

Hudson

Most of the work we’ve been doing on Hudson is still not really good enough for public consumption but we’re testing the changes we’re making on the Sonatype grid.

Hudson Site

Nexus

• Nexus Site
• Nexus: Improving Maven Central and Supporting the Maven Ecosystem
• Selecting OSS Software: 10 Questions Answered for Sonatype Nexus
• OSS Repository Hosting
• OSGi Central
• Ruby Central (We’re working on making that publicly available

Proviso

Proviso is not publicly released yet, but Alin and I have been working together to get our provisioning framework ready for a public release.

Git

We are starting to use Git heavily and soon likely exclusively. We are helping out on the EGit, and JGit projects at Eclipse and we’re trying to put a little Git server together based on JGit, MINA, and Apache Shiro.

• JGit Site
• EGit Site
• Tycho building EGit/JGit
• SShJGit @ Github

Maven Extensions

I’ll chat about these in the talk.

• Polyglot Maven Site
• Polyglot Maven @ Github
• Maven Shell
• Maven Shell @ Github

I’ll likely keep adding to the entry leading up the talk, but I thought I would get the ball rolling!

Guice-Bean Extension Layer

Our goal is to create a general-purpose bean injection layer on top of the raw custom injection API provided by Guice. This layer will take care of registering the necessary MembersInjectors as well as scanning class hierarchies for potential bean properties. All the client needs to do is decide whether or not to supply a binding for a given property.  The primary class in this layer is BeanListener:

public class BeanListener
    implements TypeListener
{
    public BeanListener( final BeanBinder beanBinder )
    {
        // ...etc...
    }
}

This is a TypeListener implementation that you can register with Guice to provide bean injection for any type. It accepts a single argument of type BeanBinder, which the client is expected to implement:

public interface BeanBinder
{
    <B> PropertyBinder bindBean( TypeLiteral<B> type, TypeEncounter<B> encounter );
}

The single bindBean method should supply a PropertyBinder based on the type of bean being injected. This means clients can customize or cache information on a per-type basis, or simply provide the same PropertyBinder implementation for all bean types. Returning null will disable bean injection for that type.  The PropertyBinder interface does the same job as BeanBinder, but at the property level:

public interface PropertyBinder
{
    <T> PropertyBinding bindProperty( BeanProperty<T> property );
}

This is the point where clients decide whether or not to bind a particular property. They can either return an implementation of PropertyBinding which should inject the property, or return null to ignore this property. This process continues until all the bean properties have been scanned – unless the client returns the LAST_BINDING constant from the PropertyBinder API, which will immediately stop the scanning for the current bean. LAST_BINDING is supposed to be used by binders who know they can’t supply any more bindings, because then there’s no point in continuing the scan.  So what does a PropertyBinding look like?

public interface PropertyBinding
{
    <B> void injectProperty( B bean );
}

Well, not much as you can see! It has a single method injectProperty which is the trigger for injecting a value into the appropriate property of the given bean. How this value is created and how it is injected into the bean is up to the client, but most clients will use the BeanProperty supplied in the original bindProperty method to do the actual injection:

public interface BeanProperty<T>
{
    <A extends Annotation> A getAnnotation( Class<A> annotationType );

    TypeLiteral<T> getType();

    String getName();

    <B> void set( B bean, T value );
}

Specifically the set method lets you inject a value into this property for a given bean instance. Notice how you can also query the generic type, name, as well as any annotations attached to the bean property. You can use any or all of this information to determine what value to inject into the property: for example by querying XML metadata, runtime annotations, maybe even pulling values out of a database.

Property names are normalized – a setter method called “setValue” has a property name of “value”

The BeanProperty currently doesn’t tell you whether it’s backed by a field or setter method. This is because we don’t need this information in our use-case and don’t believe others will, but some sort of query method could be added in the future if necessary.

Enough talk, let’s actually try and use this extension layer in a small example!

Example

We begin by creating an example Maven project:

mvn archetype:create "-DgroupId=example.bean.guice" "-DartifactId=guice-bean-example"

cd guice-bean-example/

Remove the example App files, as we’ll be adding our own files soon:

rm src/main/java/example/bean/guice/App.java
rm src/test/java/example/bean/guice/AppTest.java

Now edit the POM, first we need to add a dependency to the guice-bean-inject library:

  <dependencies>
    <!-- ... -->
    <dependency>
      <groupId>org.sonatype.spice.inject</groupId>
      <artifactId>guice-bean-inject</artifactId>
      <version>0.1.0</version>
    </dependency>
    <!-- ... -->
  </dependencies>

This will also pull in the guice-bean-reflect and guice-patches libraries

We also need to tell Maven to compile at the Java5 level, because this is the minimum required by Guice:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

We’re now ready to add our example code, let’s start with a very simple “do nothing” binder:

package example.bean.guice;

import org.sonatype.guice.bean.inject.BeanBinder;
import org.sonatype.guice.bean.inject.PropertyBinder;

import com.google.inject.TypeLiteral;
import com.google.inject.spi.TypeEncounter;

public class SimpleBeanBinder
  implements BeanBinder
{
  public <B> PropertyBinder bindBean( TypeLiteral<B> type, TypeEncounter<B> encounter )
  {
    return null;
  }
}

Well that’s fairly useless! We should at least return some property binders which in turn return some property bindings, otherwise nothing will be injected. To save on typing we’ll put our injection code in a couple of nested anonymous classes, but we could just as well have created named classes. Let’s also use the bean property to do the actual injection (for the moment we will just inject null).

package example.bean.guice;

import org.sonatype.guice.bean.inject.BeanBinder;
import org.sonatype.guice.bean.inject.PropertyBinder;
import org.sonatype.guice.bean.inject.PropertyBinding;
import org.sonatype.guice.bean.reflect.BeanProperty;

import com.google.inject.TypeLiteral;
import com.google.inject.spi.TypeEncounter;

public class SimpleBeanBinder
  implements BeanBinder
{
  public <B> PropertyBinder bindBean( TypeLiteral<B> type, TypeEncounter<B> encounter )
  {
    return new PropertyBinder()
    {
      public <T> PropertyBinding bindProperty( final BeanProperty<T> property )
      {
        return new PropertyBinding()
        {
          public <C> void injectProperty( C bean )
          {
            property.set( bean, null );
          }
        };
      }
    };
  }
}

We made the property parameter final so we could use it inside the anonymous class

Next we need to provide actual values for our bean properties. We’re free to get these values from anywhere we want, but to keep this example simple we’ll just get them from the Guice injector. So how do we access the injector while we’re still configuring bindings? Well the TypeEncounter has methods to look up the Provider for a given binding Key. But be careful – we can’t use these providers during the property binding call because the injector is still being initialized. We can only use them once the injection phase starts, such as in the injectProperty method.

Our example bean binder takes the simple name of the bean class, appends the property name, and turns it into a JSR 330 binding annotation like @Named("PersonBean.name"). In practice you’ll also want to include the package name to avoid collisions. The appropriate value provider is supplied by the TypeEncounter using a key based on the binding annotation and property type. We store the provider in a final variable so we can access it later on when we need to inject the property value into a bean.

package example.bean.guice;

import javax.inject.Named;
import javax.inject.Provider;

import org.sonatype.guice.bean.inject.BeanBinder;
import org.sonatype.guice.bean.inject.PropertyBinder;
import org.sonatype.guice.bean.inject.PropertyBinding;
import org.sonatype.guice.bean.reflect.BeanProperty;

import com.google.inject.Key;
import com.google.inject.TypeLiteral;
import com.google.inject.spi.TypeEncounter;
import com.google.inject.util.Jsr330;

public class SimpleBeanBinder
  implements BeanBinder
{
  public <B1> PropertyBinder bindBean( final TypeLiteral<B1> type, final TypeEncounter<B1> encounter )
  {
    return new PropertyBinder()
    {
      public <T> PropertyBinding bindProperty( final BeanProperty<T> property )
      {
        // simple mapping id, not guaranteed to be unique as we don't include the package namespace
        Named valueId = Jsr330.named( type.getRawType().getSimpleName() + "." + property.getName() );
        final Provider<T> valueProvider = encounter.getProvider( Key.get( property.getType(), valueId ) );

        return new PropertyBinding()
        {
          public <C> void injectProperty( C bean )
          {
            property.set( bean, valueProvider.get());
          }
        };
      }
    };
  }
}

We now have a working bean binder that maps bean properties to JSR 330 named bindings. To finish things off, let’s add a bit of logging so we can see what the binder is doing during the test:

package example.bean.guice;

import java.util.logging.Level;
import java.util.logging.Logger;

import javax.inject.Named;
import javax.inject.Provider;

import org.sonatype.guice.bean.inject.BeanBinder;
import org.sonatype.guice.bean.inject.PropertyBinder;
import org.sonatype.guice.bean.inject.PropertyBinding;
import org.sonatype.guice.bean.reflect.BeanProperty;

import com.google.inject.Key;
import com.google.inject.TypeLiteral;
import com.google.inject.spi.TypeEncounter;
import com.google.inject.util.Jsr330;

public class SimpleBeanBinder
  implements BeanBinder
{
  private final Logger LOGGER = Logger.getLogger( SimpleBeanBinder.class.getName() );

  void log( String message )
  {
    // blank method+class to remove clutter  
    LOGGER.logp( Level.INFO, "", "", message );
  }

  public <B1> PropertyBinder bindBean( final TypeLiteral<B1> type, final TypeEncounter<B1> encounter )
  {
    log( "Binding bean <" + type + ">" );
    return new PropertyBinder()
    {
      public <T> PropertyBinding bindProperty( final BeanProperty<T> property )
      {
        log( "Binding property [" + property.getName() + "]" );

        // simple mapping id, not guaranteed to be unique as we don't include the package namespace
        Named valueId = Jsr330.named( type.getRawType().getSimpleName() + "." + property.getName() );
        final Provider<T> valueProvider = encounter.getProvider( Key.get( property.getType(), valueId ) );

        return new PropertyBinding()
        {
          public <C> void injectProperty( C bean )
          {
            T value = valueProvider.get();
            log( "Injecting property [" + property.getName() + "] with \"" + value + "\"" );
            property.set( bean, value );
          }
        };
      }
    };
  }
}

OK so we have our simple bean binder, now we need a bean to test it with. How about the following:

package example.bean.guice;

public class PersonBean
{
  private int age;

  private String name;

  public void setName( String name )
  {
    this.name = name.toUpperCase();
  }

  public String getName()
  {
    return name;
  }

  public int getAge()
  {
    return age;
  }
}

This is a trivial bean that mixes field and setter injection, it is definitely not meant to represent good coding practice!

Finally we need to write a test that exercises our bean binder. The following jUnit test bootstraps a Guice injector that uses our binder along with a couple of constant bindings for each of the bean properties. Guice will handle converting the constant strings to the right types. The injector is used to inject the example bean instance into the test, where its properties are checked against the expected values.

package example.bean.guice;

import javax.inject.Inject;

import junit.framework.TestCase;

import org.sonatype.guice.bean.inject.BeanListener;

import com.google.inject.AbstractModule;
import com.google.inject.Guice;
import com.google.inject.TypeLiteral;
import com.google.inject.matcher.Matchers;
import com.google.inject.util.Jsr330;

public class PersonBeanTest
  extends TestCase
{
  @Inject
  PersonBean personBean;

  @Override
  protected void setUp()
  {
    Guice.createInjector( new AbstractModule()
    {
      @Override
      protected void configure()
      {
        bindListener( Matchers.only( TypeLiteral.get( PersonBean.class ) ),
                      new BeanListener( new SimpleBeanBinder() ) );

        bindConstant().annotatedWith( Jsr330.named( "PersonBean.name" ) ).to( "John Smith" );
        bindConstant().annotatedWith( Jsr330.named( "PersonBean.age" ) ).to( "42" );
      }
    } ).injectMembers( this );
  }

  public void testNameBean()
  {
    // check the name was capitalized by the setter
    assertEquals( "JOHN SMITH", personBean.getName() );
    assertEquals( 42, personBean.getAge() );
  }
}

If you are doing a lot of Guice testing, you should take a look at the atunit library

We’re now ready to test our example bean binder! Type the following command to kick things off:

mvn clean install

You should see the usual Maven output followed by a successful test, which should look something like this:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running example.bean.guice.PersonBeanTest
Jan 8, 2010 12:27:07 AM
INFO: Binding bean <example.bean.guice.PersonBean>
Jan 8, 2010 12:27:08 AM
INFO: Binding property [name]
Jan 8, 2010 12:27:08 AM
INFO: Binding property [age]
Jan 8, 2010 12:27:08 AM
INFO: Injecting property [age] with "42"
Jan 8, 2010 12:27:08 AM
INFO: Injecting property [name] with "John Smith"
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.785 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

Congratulations, you’ve just used Guice to initialize a plain old bean with no annotations at all!

Next: Reflection

Interested in how the BeanListener finds bean properties? We’ll take a closer look at this in the next post in this series which will cover Generic Bean reflection.

For all new development, we’ve decided to focus on Guice and build a compatibility layer for existing components. In this post, I’m going to discuss the various factors that went into the decision to move to Guice. All of Sonatype’s product are currently developed using Guice and the Guice/Plexus integration libraries that Stuart will describe in the articles that will follow over the next few weeks, and future work on Maven 3 will be based on Guice.

Why Guice?

We ultimately went with Guice because it provided a system that could be configured and customized at runtime. It was very close to the model that Plexus was using, and we felt that it would be easy for us to build a compatibility layer between the two. The primary motiviation in this decision was our ability to write that compatibility layer atop whatever framework we selected that would allow for backward-compatibility. You see, it isn’t good enough in a community this large to just move to a new framework and expect everyone to just scramble to rewrite Maven plugins. We had to find a way to support existing plugins, and existing extensions. We had to find a way to work with all of the existing code that was coded to Plexus and adapt that to a new engine.

Guice is highly adaptable. With Guice we don’t need to configure all of our components ahead of time, we can instantiate them as needed and modify the “context” with a Guice/Plexus integration layer which Stuart will describe in the following articles. The answer to “why Guice?” is explained in the code that was required to write this compatibility layer. The only way we found to make this work was by using Guice.     Other reasons included type safety, easy-to-read error messages, and OSGi support using peaberry.    All of our development uses the JSR330 standard @Inject anotations.   We’re using JSR330 instead of Guice-specific annotations to make sure that our work is more standard and portable going forward.

Focusing the Community

Aside from the technical reasons to move to Guice, there are reasons that involve the community. If our audacious goal is to provide world-class build and development infrastructure support, we need to remove unnecessary distractions from our environment. We just were not focused on Plexus, and issues would come up in Plexus that needed to be supported which distracted from the core effort. We’re not just using Guice. Because we are starting to rely on it, we appreciate the need to work closely with a project like Guice and contribute back to that community.  Stuart is a committer, and we wanted to collaborate with others and use a framework used widely by others.

Maven’s goal was never to create a dependency injection framework, it was always focused on builds and the infrastructure that supports development. Not long ago, we were contemplating what it would take to improve Plexus, we looked at the effort required to document and support Plexus going forward, and it just didn’t make any sense for us to continue to apply precious time and effort to a problem that had already been solved by several others. It makes sense to focus the community, and moving to Guice will allow us to devote more of our own resources to supporting the central projects and products.

Making it Easier to Extend

When your project or production uses a standard tool, you increase the audience that can customize it. If the goal of Maven is to create a solid foundation of infrastructure for others to build upon, it only makes sense to adopt something more standard. Maven and products like Nexus should be judged by the number and variety of plugins that have been developed for them, and this is something that attract most new users to Maven (the abundance and variety of Maven plugins). Anything we can do to make it easier to extend these systems is the right thing to do for the “ecosystem” I described last week.

If you wanted to write a plugin for the initial version of Nexus two years ago, you would have had to know a lot about Plexus. There was nothing particularly wrong with Plexus, it had a well-defined interface and it served its purpose, but there wasn’t very much documentation, and requiring some knowledge of Plexus for plugin developers was reducing the size of potential developers. In the past year, we’ve made a course correction, and you can write a Nexus plugin without having to learn any dependency injection framework. What has made this transition possible is the flexibility of Guice.

Summary

Stuart’s going to dive into the technical details in the next five parts of this series. If you are a developer interested in the implementation of Plexus and Guice, you’ll find these posts to be a good starting point for learning about we’ve implemented this compatibility layer.