We have a Jenkins continuous integration server that among other things allows us to run Maven release builds centrally using the M2 release plugin for Jenkins.
This setup worked fine with Subversion, but needed some tweaking after our recent switch to Git and github:enterprise. Here’s what I did to make it work:
- The release plugin needs write access to the upstream repository, so I had to configure Jenkins to use an ssh key associated with a real account instead of a deploy key that only gives read access.
- To tie the release commits to the Jenkins server, I configured the global “user.name” and “user.email” settings of the Jenkins account to “Jenkins” and “jenkins@…”.
- Finally, I hit an “”ref HEAD is not a symbolic ref” error caused by Jenkins by default using a detached HEAD. A quick web search uncovered a solution as described by Stephen Connolly in a related CloudBees user forum thread. The solution was to set the “Checkout/merge to local branch (optional)” option under advanced Git settings on the Jenkins build configuration screen.
With that setup in place, we can again cut new releases with just a single click of the “Schedule Maven Release Build” button. Nice!
Today we announced the release of Apache Jackrabbit 2.3.0. It’s the result of over nine months of development since the Jackrabbit 2.2 release, and contains changes related to over a hundred new features, improvements and bug fixes. See the release notes for the full details.
Before you rush in an upgrade all your production systems to Jackrabbit 2.3, note that this release has explicitly been marked unstable. In fact all 2.3.x releases will be unstable development releases cut directly from trunk. A stable 2.4 maintenance branch will be created in a few months for production-ready releases. See the Jackrabbit roadmap for more details about our new unstable/stable release strategy.
The com.adobe space on Maven Central has so far been used by various third parties (including myself from before joining Adobe) to make Adobe releases available to Maven clients.
We want to have better control over that space and to make it easier for Adobe projects to publish their releases on Maven Central, which is why I’ve requested a repository that we can use for this. We still need to figure out the internal processes by which new releases can be posted there, but at least the technical bits are already being taken care of.