Guicing up Hudson: Making life easier for developers with JSR-330


February 10, 2011 By Jason van Zyl

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.

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][1] 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.

[1]: https://github.com/sonatype/hudson-jsr330
[2]: https://github.com/sonatype/hudson-jsr330/tree/master/matrix-smoothie-example-plugin
[3]: http://www.sonatype.com/sonatype-professional—hudson-professional.html

  • http://twitter.com/0x4C4A0A46 0x4C4A0A46

    Hudson already has Maven 3.x support, and has had it for quite a while now. It was provided independently of Sonatype….

    • Stuart McCulloch

      As the old quotation goes, “Let a hundred flowers blossom” – we’ll be contributing various pieces of code back to the community, and no doubt there will be some overlap in functionality here and there. Just like there are Maven plugins which provide essentially the same features (such as the shade and jarjar plugins) and overlapping projects hosted at Eclipse and Apache. This is healthy imho.