Guice & OSGi

[Jason van Zyl <ja...@sonatype.com>]

For folks that want to do some forward looking research and reading on Guice and OSGi here are a few resources.

Of course, you can probably find all the standard Guice resources yourself. But ultimately we are going to be interested in the most agnostic form of dependency injection so I'd like to stick with JSR 330 as much as possible. If we need to create a new plugin API then we might make some additions but JSR 330 at the core.

We, Sonatype, have attempted to not require any alterations in the existing code. In a nutshell an entirely transparent drop-in replacement for Plexus. Guice does not do classpath scanning, or have lifecycles so we've had to add that support in order to make things work. Nexus uses a lot of the same facilities Maven does so we attempted to make this work for Nexus before attempting this with Maven. The code that we've created to "shim" Plexus idiom and behaviour into Guice is here:

http://svn.sonatype.org/spice/trunk/spice-inject/

It's just one set of binaries versus another to use Guice over Plexus. It simply can't be any other way because all the old plugins and components that have been created need to be supported. So it's not a simple matter of just switching IoC containers. This was not a small job and it has to be a perfect mimic or lots of things will break. It's all there in the code and Stuart is going to try and document this in the short term so people can read about it. We'll figure out in the next week how to make this easy to try for people like Kristian who want to take a look.

The next phase is using OSGi for that we plan to use Stuart's Peaberry project which you can find here:

http://code.google.com/p/peaberry/

I don't think that OSGi is ideal for typical application development but for plugin-based systems we've just run into the brick wall too many times with Maven 3.0 and Nexus that we need the isolation that OSGi provides and there's no point in rewriting this stuff. But we still are trying to figure out a way not to expose everyone to OSGi. So that users again will not have to do anything differently in the way they extend Maven. Where our problem is going to be is having correct bundle information at runtime. So for JARs that were produced before this work we have a bit of a problem to sort out.

Stuart is happy to answer any questions as this is primarily his effort thus far. We're waiting for Kristian to get involved. This stuff is very "hot" :-)

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org