Two weeks ago we proposed that [Hudson plugin authors be able to use dependency injection][1] 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][2]. 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][3] and it appears to have been absorbed as part of [JENKINS-8897][4]. Continue reading →