A fortnight ago, the Eclipse Foundation announced the release of Hudson 3.0, the eponymous continuous integration system. The roots of the Hudson project can be traced back two years ago, when Jenkins was forked, and the proposal to join the Eclipse Foundation as a neutral hosting organisation. Although both forks continue along together today, and Hudson 2.2.1 was released after the fork, Hudson 3.0 marks the first official Eclipse project release.
Hudson is available in two forms; a simple web archive (which just contains the core features) and a bundled version (which contains a number of useful plug-ins). These are distributed via Maven Central as well as from the Eclipse foundation site.
One of the reasons for taking so long is the IP cleanup required. In May 2011, InfoQ noted:
The Eclipse Foundation pays a significant amount of attention to IP cleanliness, so the creation of a project proposal is just the start of a long journey. In addition, the re-licensing of the existing codebase to move to the Eclipse Public License will be fine for code contributed via Eclipse company members (Sonatype, Oracle) but any outside additions to the core may need closer examination before the code can come through.
InfoQ caught up with Winston Prakash, project lead for the Hudson project, and began by asking him why IP cleanliness is so important:
Prakash: When Hudson became a top level technology project at Eclipse Foundation, it needed to comply with Eclipse IP policies, which help to mitigate IP risks and make the product more attractive for enterprises to include it in their own products. This supports one of the main goals of Hudson which is to make it an enterprise-class product.
InfoQ: How much change was needed for the core infrastructure to bring it into compliance?
Prakash: The Eclipse foundation legal team has gone through every line of code base (literately, they have tools to analyze the code) of the product to make sure it complies with all the above. Every third party library included in Hudson has gone through the legal process. It took more than a year for us to gain compliance.
InfoQ: Does the 3.0 release represent a new beginning for Hudson, and what is its future in terms of plug-in compatibility between that and Jenkins?
Prakash: We tried our best not to break compatibility between the two. We have not changed any existing APIs, though we provide enhancements. We will continue to support Jenkins plugins and verify them in our releases.
We also continue to encourage Hudson users to develop new plugins for Hudson.
InfoQ: Why is it important that Hudson has disabled the automatic JDK install for builds?
Prakash: This is a licensing issue. As per the Oracle Legal team, the JDK can not be installed with out accepting the license terms. Hudson and Jenkins were installing JDK via screen scraping, which was reported to us as not legal. We promptly disabled the automatic JDK install, until we get a proper REST API from the JDK team.
InfoQ: The Groovy plugin was removed a key dependency for the framework; why is that? Can it still be used?
Prakash: The main reason Groovy was removed from Hudson core is because of provenance issues. The Eclipse foundation could not get legal provenance from the Groovy team.
Groovy support is still available through an external plugin. The advantage is, scripting support is abstracted now, so scripting through other JVM languages such as Scala, Jython, JRuby may be possible in future.
InfoQ: Where and how is the Hudson 3.0 plugin site now located?
Prakash: Hudson specific plugins and those plugins forked to make them Hudson compatible are here:
- All Hudson 3.x plugins – https://github.com/hudson3-plugins/
- All Hudson 2.x plugins – https://github.com/hudson-plugins/
InfoQ: What is the future of Hudson 3.x?
Prakash: Stability is the utmost importance for Eclipse Hudson. We are dedicating the next release (3.1.0) specifically for performance improvement. Though we continue to add features based on demand, stability and performance are our highest priority.
