Today we started rolling out the first of our proposed JSR-330 Dependency Injection changes to Hudson back into the Hudson community. We’re giving it back because we think it is going to make a huge difference for Hudson’s future development. As more and more libraries move to JSR-330, we’re going to see a lot of possibilities open up because of these changes. With today’s donation, we’re making it easier to extend Hudson, we’re reducing the effort required to write a Hudson plugin, and we’re helping to put in a new foundation for the next level of Hudson interoperability and performance.
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.
For my talk today at JFokus today I’ve taken the liberty of starting some notes for folks interested in attending. There’s a lot to cover and so I thought I would try the approach of providing some material up front so the session can be more of a dialog. I’m going to attempt to cover everything in the picture below and save the demos folks might want to see for the Sonatype booth. Happy to chat with folks and do any demos before and after the presentation. Just stop by!
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.
Continue reading →
In the first two articles in this series you learned why Sonatype has decided to move our development efforts from Plexus to Guice and you’ve also been introduced to Sonatype’s efforts to create a Guice/Plexus integration library to make the migration from Plexus to Guice seamless. In this post, I’m going to dive into the details of bean injection in Guice, and I’m going to demonstrate how you can use the general-purpose bean injection layer in the Guice/Plexus integation library to intialize a bean. This post is highly technical and is meant for developers interested in the details of our attempts to bridge Plexus and Guice. Continue reading →
When we started the Maven project, dependency injection was still developing. Spring was just starting out and the Avalon project at Apache was really the only IoC framework around. While the concept seems second-nature by 2010, in 2002, it wasn’t a primary focus of the initial efforts of the Maven community but it was something I felt had to be in place for the development of Maven 2. We knew we needed some sort of component framework, some standard mechanism to instantiate plugins and configure them based on a set of configuration points, and, at the time, Plexus filled the gap. Plexus was exactly what we needed because it evolved with the requirements of Maven, and I think that Plexus served us well for the past few years but it’s time to let go. I never felt compelled to switch until Guice 2.0. Guice has the capabilities and adaptability we require in Maven.
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. Continue reading →