Hudson's Bright Future

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:

- The Hudson WAR distribution incorporates over 100 dependencies, a troubling number of which are forked. As result, there is no easy way to incorporate improvements from those forked projects in Hudson. It's also not very easy to know why they were forked in the first place.

- The core technology for the user interface in Hudson is Jelly. We used Jelly in Maven 1.0, but took it out more than five years ago for Maven 2.x because it is not maintained and very difficult to work with. Hudson is still dependent on Jelly, but there are many more standard, and flexible, options for the UI technology: choices like GWT, Vaadin, or JSF.

- Hudson has had minimal project infrastructure. There are extremely limited unit tests, and integration tests that leave a lot to be desired (e.g. they don’t run on recent versions of the Mac OS X). Weekly builds of Hudson without a sophisticated automated test infrastructure is just not wise. Winston and I will propose a plan to clean up some of the testing infrastructure as a first priority. We're not in a rush to push out releases where the community has to act as QA. It's great to get feedback from users but we think a better job can be done on the testing front to alleviate this burden on users. It's not glamorous, it takes a lot of time, but it's necessary if you value stability and quality.

- Little to no effort has been made to track the provenance of the code, and there are numerous licenses that are used throughout the codebase. The licensing issues can likely be resolved using different libraries, and doing some modularization, but the provenance and IP issues are of utmost importance when you care about downstream consumers. These issues are of little or no concern for SaaS providers, but critical for companies that need to deliver software used on-premise.

So, I’ve told our developers to stay focused on improving Hudson's infrastructure and fundamentals. Here's our current work log:

- Testing infrastructure, and bolster the unit and integration tests
- JSR330 support for plugins
- JAXRS support for web services
- Maven 3.x support (94% of Hudson installs also use the Maven plugin)
- Eclipse integration
- Netbeans integration
- Assessment of the current Hudson architecture
- JSR330 architecture work to modularize the Hudson core
- Using a standard view technology like GWT, Vaadin, or JSF
- Inspection of non-standard/forked dependencies and trying to re-align with current mainstream releases
- Isolating code with problematic licenses and trying to reduce the license footprint
- Using standard Maven plugins for creating ancillary Hudson distributions

I’ll describe all of this in greater detail in subsequent blog posts.