At a recent Jenkins meeting, the discussion turned towards whether a reconciliation with the Hudson project was possible (after the Hudson proposal to move to Eclipse.org was released), and what would be required for that to happen. The stated requirements appear to be in conflict to moving towards either Eclipse or Apache foundations, and therefore in a reconciliation with Hudson.
As the discussion in Agile development moves from continuous integration (CI) to continuous deployment, CI servers are doing more to automate the overall build process. Atlasian, which today released Bamboo 3.1, has implemented a new feature called Tasks that the company hopes will aid developers in their continuous deployment efforts.
With the recent proposal to move Hudson to the Eclipse Foundation, there has been speculation as to whether this will lead to a coming together of Jenkins and Hudson, or even whether the code can be relicensed under the EPL. A discussion is taking place later today on the Jenkins IRC channel to discuss whether the Jenkins community wants to be part of this or not.
Oracle has created a proposal to move the Hudson project, including ownership of the trademark and domain name, to the Eclipse Foundation. In addition to the existing commercial backers (Oracle and Sonatype), other commercial supporters are keen to see Hudson move to an independent organisation and process, and will also be adding committers to the project.
The first significant release of Hudson since the Hudson/Jenkins fork has been released, with a new versioning scheme following OSGi/Semantic Versioning going forward. This includes a new JSR330 dependency injection model to make it easier to run in an OSGi runtime as well as decoupling from specific Hudson annotations.
Late last month Google released Guice 3.0, a Java framework that implements the dependency injection (DI) design pattern. The motivation behind Guice was to make it easier for programmers to write DI code by reducing the need to write boilerplate factories. This article examines the new 3.0 features, loks at how Guice 3.0 supports Spring DI, and introduces Guice 4.1 (a.k.a. MiniGuice).
Whilst Jenkins 1.397 has been released, Sonatype have been pressing on with build and architectural changes to Hudson. In order to facilitate further developer interest, the Hudson codebase will be moved back to GitHub.
The first Jenkins version, 1.396, has been released with upgrade scripts that can help migrate an existing Hudson instance. Meanwhile, Oracle confirms the continuation of commercial Hudson support, and Sonatype puts their weight behind Hudson.
The votes are in, and the community voted to rename Hudson as Jenkins in a 214 to 14 split. The infrastructure is ready but not yet in use, with a migration timeline to be announced in advance to give developers time to migrate to the new organisation. Oracle will continue to support and develop Hudson at the java.net infrastructure, but for how long?
Oracle has responded to the Hudson community about how they can keep control of the Hudson name but let the community do the work. The community has responded with a vote on renaming the Hudson project to Jenkins to escape from Oracle's legal sabre-rattling.
With Oracle having applied for the trademark on the Hudson project name, and potentially putting the future of the Hudson project in future jeopardy, the Hudson developers have proposed renaming the project to Jenkins. The developers are keen to emphasise that this is a rename, not a fork, of the project since the same developers will continue to work on the renamed project.
The Hudson developer community has moved Hudson's source code away from Oracle controlled source infrastructure, and is considering a fork. Oracle is now pleading for this not to happen. How did relations sour, and what is the future of Hudson?
Sonatype have created a mirror of Maven Central in Europe. If you use Maven, and you're based in Europe, you should update your maven settings to point to it for faster asset acquisition.
Sonatype today announced the release of Maven 3, the biggest change since Maven 2 was released in 2005. The release of Maven 3 has been backed up by significant automated testing using open-source projects in the field to try and prevent backward incompatibilities. As a result, Maven 3 should just be a drop-in replacement for Maven 2, with an increase in performance.