The creator of Apache Maven. Jason is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Hudson’s Bright Future

02.07.2011
| 6020 views |
  • submit to reddit

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.

 

From http://www.sonatype.com/people/2011/02/hudsons-bright-future/

Published at DZone with permission of Jason Van Zyl, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Geoffrey De Smet replied on Mon, 2011/02/07 - 6:49am

Like any succesfull software project, there's lots to improve on Hudson. I think it's great that Sonatype identifies the issues and are signing up to fix them.

But what about the elephant in the room? What about Jenkins? Technically, there's little or no difference with Hudson at this point.

I (and probably most of the community) would rather see just 1 trieving effort, especially because there's no big technical design discussion on the base of this fork. So when KK et al (the guys who have done the most work on Hudson), forked Jenkins, it seemed clear which project would staginate (Hudson) and which woulde thrive (Jenkins). Untill now of course: now there's a real fork, a real duplication of improvements, a real reason to doubt to which project to contribute... Is this fixable? What should be fixed in the Jenkin's governance to allow Sonatype to work on Jenkins too? Are they willing to fix it? Hudson's governance is apparently not willing to fix the issues KK et al have with it.

Mats Henricson replied on Mon, 2011/02/07 - 7:03am

So we're accepting tech politics submissions on this site now?

Please, no more of this! Write it as a press release and let people read it if they find it interesting. To most people out there, it just isn't, since Jenkins is going to rule.

 

Artur Biesiadowski replied on Mon, 2011/02/07 - 7:13am

Will there be any showstopper for both projects just 'stealing' each other commits for a time being? I think both are licensed quite liberally, so before they diverge too much, there should be a good deal of cross-pollination possible.

Damien Lepage replied on Mon, 2011/02/07 - 9:56am

What a waste of energy in this ego war ...

Jonathan Fisher replied on Mon, 2011/02/07 - 10:45am

I couldn't agree more. The Jenkins lead took advantage of the general hate for Oracle and dragged the Hudson community into it. The community acted as pawns in his game. Stupid stupid stupid... I've never seem a project fork over infrastructure... The real elephant in the room is that the Jenkins developer is an ex-Oracle employee hell bent on destroying an Oracle revenue stream and is willing to bait and manipulate the Jenkins community into doing his bidding.

Jess Holle replied on Mon, 2011/02/07 - 5:41pm

Really?

After watching Oracle willfully torpedo relations with one open source project community after another, I guess I'd not jump to any conclusion that the split was based on a grudge by the Jenkins lead against Oracle revenue streams.  There seemed to be valid concerns about Oracle's assertions about trademark ownership.  Oracle could have resolved these in a fairly amiable fashion, but chose not to.

I have a hard time believing that the Jenkins lead is the elephant in the room here.  Rather it's hard not to see this as just another part of the same trend shown seen with the OpenOffice vs. LibreOffice fork.

Mats Henricson replied on Tue, 2011/02/08 - 2:51am in response to: Jess Holle

Amen!

The vote was 215 for and 15 against a fork, or something like that. It is clear that the whole community is going Jenkins, and Oracle is left with breadcrumbs. Now it does what it can to use sites like this to hide the fact.

"Hudson's Bright Future"? Really? Jason Van sounds like Baghdad Bob to me!

 

Bruno Borges replied on Wed, 2011/02/09 - 8:05am

The Future of Hudson

What a bright future Hudson will have... Unsubscribe @ hudson

ionuion@yahoo.com (not verified) replied on Thu, 2011/02/10 - 7:03am

I do not contribute to Hudson in any way. I'm an avid simple user.

Hudson is the finest developer tool I have used. It gets jobs done well and is as developer-friendly as can be. Always a pleasure to come back to that dashboard.

I hope that the plans to extend it do not translate into plain old bad critique. If it's 10% that needs to be criticized, let's not forget the 90% that need to at least be mentioned, actually praised.

Thanks to those who have made Hudson what it is today.

The plans look great too.

Chris Treber replied on Thu, 2011/02/10 - 8:11am

We need a "desaster containment" tag for posts I guess...

Yochanan Berkowitz replied on Mon, 2011/08/29 - 2:49pm

We could not blame Oracle for their response.  Both parties have acted appropriately according to their priorities. -Yochanan Berkowitz

Thomas Kern replied on Thu, 2012/09/06 - 10:48am

Very nice. Didn't realize it was that bad. Ripping out jelly sounds like a very nice improvement. Never really understood it in the first place. Don't existing plugins that change the hudson UI "extend" jelly. What happens to those existing plugins once the hudson UI is changed?

http://www.java-tips.org 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.