Author Archives: Jason van Zyl

Hudson Plugins, Meet Dependency Injection: JSR330 Support Now Available


March 2, 2011 By Jason van Zyl

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 →

Hudson moves to Github! We're not forking around!


February 15, 2011 By Jason van Zyl

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!

Guicing up Hudson: Making life easier for developers with JSR-330


February 10, 2011 By Jason van Zyl

Today we started rolling out the first of our proposed JSR-330 Dependency Injection changes to Hudson back into the Hudson community. We’re giving it back because we think it is going to make a huge difference for Hudson’s future development. As more and more libraries move to JSR-330, we’re going to see a lot of possibilities open up because of these changes. With today’s donation, we’re making it easier to extend Hudson, we’re reducing the effort required to write a Hudson plugin, and we’re helping to put in a new foundation for the next level of Hudson interoperability and performance.

What does this mean for you as an end-user?

Guice is emerging as a lightweight Dependency Injection standard. We’ve moved the core of Maven to Guice over the past two years and it has dramatically increased performance and opened up possibility for integration with other tools and libraries. Since Guice is implementing JSR-330 standards, what we’re really doing with this effort is moving Hudson to a more standard, more maintainable architecture. As an end-user, you will likely notice increased stability as the core becomes more modular, easier to maintain and test. You should also expect greater integration with other tools that can speak the JSR-330 standard. This includes components that use both Guice and the Spring Framework.

Continue reading →

Hudson's Bright Future


February 3, 2011 By Jason van Zyl

We believe that Hudson users can look forward to a long, bright future.

Working with the community, Oracle and Sonatype are each putting a number of full-time engineering resources on Hudson. The Hudson lead, Winston Prakash from Oracle, is highly skilled, very thoughtful, and he cares about the community. He is also the first person to create detailed, comprehensive architectural documentation.

This kind of documentation (which has never been available in the past) is required to understand how Hudson can be improved. The lack of architectural documentation, along with how decisions were made, left the Hudson community mostly dependent on a single individual for core changes.   Let’s be honest about where this led: Continue reading →

How to build a RAP application with Tycho


January 17, 2011 By Jason van Zyl

Holger Staudacher, at EclipseSource, has a good writeup of his experience evaluating Tycho for the Runtime Packaging Project (RTP). Here’s an excerpt of what he has to say:

Recently I played around a little with Tycho because we evaluated it for the use in the RTP project. As a test case, I decided to try to build a RAP application with Tycho. With building I mean compiling and packaging the artifacts into a WAR file in order to deploy them on a Tomcat or another Servlet Container. I have to say that I’m really impressed with Tycho. Before this experience…

It’s great to see different projects trying Tycho at the Eclipse Foundation: having standard recipes for building RAP applications would be extremely useful addition for the community. RAP is not something that Sonatype is directly involved with so it’s great to get this varied perspective, and different applications types so we can make sure Tycho will work for as many use cases as possible. Thanks Holger!

Holger has some good examples at Github, and you can find his original blog entry here.

We are currently working on submitting the CQs for Tycho so we can move the project over to the Eclipse Foundation. I think Wayne Beaton said he wanted to help with those CQs. Right Wayne? :-)