Hudson Plugins, Meet Dependency Injection: JSR330 Support Now Available
Join the DZone community and get the full member experience.Join For Free
Two weeks ago we proposed that Hudson plugin authors be able to use dependency injection through the JSR-330 standard. This change makes it easier to write Hudson plugins without having to dig into Hudson internals, it provides greater separation between plugins and Hudson core, and it makes it much easier to test plugins without having to bring along core Hudson objects.
These changes are now in the core of Hudson. Even though JSR330 can now be used by plugin authors these changes should, in no way, affect plugin authors using the existing API. Since this question came up on the mailing list, I’ll give a short description of how it works here. The JSR330 integration allows you to take advantage of JSR330, if you wish, by using an alternative plugin strategy. Our new plugin strategy interoperates with the existing, classic plugin strategy. Sonatype’s Hudson Professional distribution actually ships with a mixture of JSR330 plugins and classic plugins and we find this works quite well. We tried to make it easier to use new strategies for wiring up plugin, and Stuart McCulloch has offered this strategy on the Jenkins development list and it appears to have been absorbed as part of JENKINS-8897. Now that the absorbtion of our first proposal is complete we will move on to our next proposals. These proposals are a mixture of project infrastructure proposals and core Hudson proposals.
New infrastructure for plugin developers. Winston Prakash and I have been working on setting up a new infrastructure for Hudson plugin Developers where it’s very easy for them to develop, stage to Nexus OSS, and synchronize their plugins to Maven Central. As part of this work Sonatype is also working on making Hudson plugin development dead-simple with m2eclipse. Winston and I have started testing this new infrastructure with a few plugin developers over the last couple of days and it’s working out quite well.
Plugins update site generation from Maven Central. Once Hudson plugin developers have synchronized their plugins to Maven Central we want them to be made immediately available to Hudson users. I have been working on a plugin for Nexus that will listen for incoming changes to Hudson plugins and dynamically modify the JSON metadata required by the Hudson update manager. The information about available Hudson plugins will be made available from Maven Central as a set of REST services. The integration possibilities here are very interesting.
JAXRS-based REST API. Jeanfrancois Arcand has been working on adding support for the dynamic addition of resources in Jersey and adding support for a JSR330-based component provider. We want to be able to use JSR330 and we want Hudson plugins using JSR330 to be able to dynamically register their own REST resources. Once this work is done on Jersey we will be making the proposal for its inclusion to the Hudson core.
Modularizing the Hudson core using JSR330. Stuart McCulloch has started analyzing the Hudson core and finding ways to help us reduce the complexity by breaking it apart into distinct JSR330 components. This will be an ongoing process, but one we believe will help us with all other work we intend to do with Hudson.
Hudson Core Testing. There is simply no way that we can aggressively refactor the core and know the changes are not harmful without drastically increasing the amount of testing done. This will be another ongoing process and I believe the most important contribution we will be making.
We are moving more carefully and probably slower then we might like, but we feel that, in order to aggressively add features in the future, the testing infrastructure, development infrastructure, and core features need to be in place. All this work I’m talking about will likely take a release or two to get in place but once that is done we will be moving at a radically different pace.
Opinions expressed by DZone contributors are their own.