Sonatype Blog
Posts by Jason van Zyl

Let’s talk about security. You may have seen that Sonatype released research on the security of some of the most commonly used open source components. To be honest, the results surprised me. However, now that we are aware of the realities, it’s important to be practical about this.

Join me for 30 minutes at 11:00AM EDT (GMT-0400) on Thursday, April 12, when I will be sharing some of our findings and my thoughts on how we can build a more healthy open source ecosystem.

Register here

Hope you can make it,

Jason

We’re very excited about the proposed move of Hudson to the Eclipse foundation.  To get the project off the right start in its new home, Sonatype has committed to donating all our Maven 3.x related work to the Hudson project. This includes the Maven 3.x integration for Hudson itself, our Eclipse integration, and our Maven Shell integration.

To start the process of donating our Maven 3.x related work we are inviting everyone to an informal webinar where we’ll walk through and demonstrate the complete Maven 3.x feature set of the Hudson integration. We’ll field any questions, listen to feedback and record the session so that anyone may use the recording as a reference for the Maven 3.x feature set. Everyone is welcome!

The specific features of the Maven 3.x builder for Hudson we’ll be talking about at  this  webinar is as follows:

Configuration Features

• Maven installations
• Global configuration templates
• Settings and toolchains configuration upload and builder selection
• Maven 3.x builder configuration

Build Comprehension Features

• Basic summary: goals, module list with status, name, duration
• Runtime details
• Module details: active profiles, produced artifacts, consumed artifacts
• Artifact details for the entire build

Advanced Features

• Auto archiving of artifacts
• Auto fingerprinting of artifacts
• Up/downstream triggers

We will also talk about how we integrated GWT, some of the benefits and drawbacks, and whether we think it’s a viable technology for Hudson. We have also created 10 new plugins and we’ll talk about some of those. Again, the webinar is going to be very informal, we really want feedback and questions from users in the Hudson community.

Webinar Details

Webex link: Community demo for proposed Maven 3.x support in Hudson

Date: Wednesday May 11th, 10:30AM-12:00PM EDT (GMT – 04:00)

At Sonatype, we’re very excited about the Hudson proposal that has been posted to the Eclipse Foundation website today. We believe Hudson moving to the Eclipse Foundation is the best way forward for both the Hudson and Jenkins projects. Having Hudson at a mature OSS foundation like Eclipse gives enterprise users the confidence that Hudson will remain vibrant and will continue to grow, and provides an opportunity to reconnect the Jenkins and Hudson communities back into a single focused community. Sonatype supports Eclipse as a Strategic Member because we’ve been impressed by the infrastructure, process, and approach to project oversight. It’s an ideal place for Hudson to mature.

Looking at the interested parties in the Hudson proposal it’s apparent that more resources than ever will be poured into the Hudson project. Oracle and Sonatype have been working diligently to add fundamental architectural improvements to Hudson — which has paved the way for a new stream of innovation. VMWare and Tasktop have also indicated that they will be providing additional development resources, and we’re keen to start collaborating with them.

Sonatype also hopes to attract more enterprise-class contributors by taking the lead and contributing our core Hudson innovations to Eclipse. This includes all of the Maven 3.x integration that we have created to date. We were originally only going to provide a portion of our Maven 3.x integration to the OSS community, but we are so excited about Hudson moving to Eclipse we want to stimulate community adoption and wider participation by providing the best Maven integration possible.

The Hudson proposal still needs to go through the 30-day review period within the Eclipse community, but we really think Hudson has found its new home.  The Eclipse Foundation is a highly respected organization, has proven to be a vendor neutral, and has fostered many successful projects.   Eclipse would be a great place for Hudson and Jenkins to reunite and now would be an ideal time.   It can only be a good thing for users and I sincerely hope that the Jenkins team will seriously consider this option.

Hudson plays a key role in Sonatype’s commercial product portfolio so we’re committed to making the project succeed at Eclipse. We will offer commercial support and value added functionality in our ‘Professional’ version of Hudson. We are planning to contribute all commercial work we’ve invested in thus far to the Hudson project but we have more commercial features in the pipeline. Our customers tell us that along with Apache Maven, Nexus, and m2eclipse, Hudson is a critical part of their software development infrastructure. Hudson will be successful at the Eclipse Foundation and Sonatype plans to take an active part in that success.

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]. (more…)

First, I’d like to address some misinformation. The use of Github itself was never an issue. It was how the original movement of the sources to Github was executed, and why, that created tension. Github is just a tool and it is a better choice for source control, at least in the short term, for several reasons:

• Rich REST API: Good for IDE and tooling integration and will allow some cool workflows which can empower contributors.
• Known quantity: Developers are very familiar with Github and its workflows. It’s easy for developers to interact with us by forking, making modifications, and submitting pull requests.
• Git repositories are available over HTTPS which makes collaboration at larger organizations easier.
• SVN interoperability: There are still many developers who are comfortable with their SVN tool chain and Github makes working with Git and SVN simultaneously a possibility

We proposed using Github on the Hudson list, and in short order agreement was reached and the move was initiated. Winston did the infrastructure work last night to push the sources for Hudson over to Github. It was really that Simple. It’s amazing how smoothly things go when you clearly communicate your intentions to all stakeholders. We hope to keep improving the infrastructure for Hudson so if you’re interested please join the Hudson Dev list!

You can also keep track of Hudson developments by following us on Twitter!