Sonatype's Hudson's bright future - answer

So Sonatype's Jason Van Zyl posted about Hudson's future. I wonder if that response is related to Hudson-Dev's email thread "The Future of Hudson".

While I agree with some of the things Oracle and Sonatype are doing, I strongly disagree with the wording of this post and some of the comments.

• "mostly dependent on a single individual for core changes" (aka hudson dependance on KK). There are 115 different contributors in core according to git (for jenkins, but that shouldn't be a big difference in hudson). yes he made the main decisions at start, but there are now more than 350 hosted plugins. From that perspective, his decisions sounded right


• criticizing jelly ? I agree that it's not the best choice for a project starting today. But it's not that bad. And have you looked at how much code jelly represents in the plugins ? If I look at the official plugins from middle July 2010: 420k lines java, 44k jelly. That's 10%, a huge problem, right? And it's not because jelly didn't make sense for maven that it didn't for hudson. Actually it makes much more sense in hudson than in maven.


• lack of documentation: most projects lack it. Even Maven


• "too many forked dependencies". Think of them as patched dependencies, not forks. Who hasn't done that in the enterprise world? You know how hard it is to get a commit upstream sometimes. And it's easy to know why they were forked. Check the release logs for the deps. Or ask !


• provenance: commits come with issue number and/or link to online discussion / report in the mailing list. Code comes from commits. Do you mean it could have been copied from another project without appropriate copyright ? This can happen anywhere. And it's solved the same way everywhere: by rewriting the code. Nothing dramatic.


• licensing issues: yes you're right. BTW, mentionning Saas really sounds like attacking Cloudbees...


• automation tests. Yeah ! All for it. There are 800+ tests right now in test harness. It's not that bad then. And you know how hard it is to come up with a good coverage right ? Maven 2.0.x took a long time to stabilize... As for providing tests for all plugins, it's hard. In maven it's easier because most are not hosted by Apache itself (think codehaus, etc)


• "maven 3.0 support" in your worklog sounds like hudson/jenkins doesn't support it. How does that run then ? You might want improving it, or providing an alternative. Fine. But don't do as there's no support for maven 3.0 today in hudson/jenkins.
  

I could go on but I don't want to be too picky.

To summarize. Technical debt ? Oh yeah. Old dependencies? Double that. What kind of old projects doesn't have that ? How many times did you rewrite maven already ? You know it's hard to get it right the first time.

The reason I wanted to answer Sonatype's post was that line.

"Working with the community, Oracle and Sonatype [...]"

I think (and I may be wrong) that you've been working with a subset of the community. You didn't seem to publish your RFEs on the wiki on in Jira when the hudson developers asked (did you?).

You probably worked with Oracle and some of its customers, perhaps getting paid for your company's work. Nothing wrong about that in itself. Even great!

But please don't say 'the community'...

Anyway, the wording aside, I can't wait to see your contributions. I am sure they will help to make Hudson (and indirectly Jenkins) a better product.

The Future of Hudson

Looks like quite a few people think that unssubcribing the developper mailing list is the way to put "the saga behind".

Hudson vs CruiseControl, presentation from 2008

(Note: Because it's historical, I will still keep the hudson name in that post, but that content of course also applies to Jenkins.)

Looks like Google Docs doesn't allow viewing my Open Office presentations. I digged that old Hudson vs CC presentation I made in 2008. You may find some interesting notes in particular:

• Slide 13: some stats on hudson source


• Slide 14: some stats on hudson releases where I plotted releases from 1.04 to 1.210 (pretty impressive rate at the time !)


• Slides 15&16: Hudson success factors


• Slides 17: Benefits


• Slides 18: 4 things to do:
  
  
  
  1. Try it
  
  
  2. Like it
  
  
  3. Use it
  
  
  4. Contribute
  
  
  
  

Enjoy!

The Hudson rename/fork. Part 1 - a question of fears and mis-communications

(Disclaimer: I am a registered Hudson developer, although I haven't commited much on the project. I use Hudson on site at most clients. I have always been interested in CI and am a former external contributor to the cruisecontrol project. I also voted yes to the fork/rename, for reasons I may explain in a further post)

For those who don't know, the renaming/forking of Hudson into Jenkins was decided a few hours ago, 214 votes against 14.
Although a lot will happen around those projects in the next future, I think it is important to have a look at this event right now.
To me, this renaming/fork symbolizes the big culture gap between open source and corporate driven projects, and I could add, between Sun (RIP) and Oracle.

The information I gathered here come from the different public documents found on the web and a few private conversations/communications with some of the main actors of Hudson's community.

I'll cut this post in 4 sections

• an historical perspective


• an analysis of the current problem


• some previsions about what may happen


• a few learnings for current or wanabe open source projects and/or for companies wanting to build models around open source

The first 2 sections will be addressed in this document, the 2 later ones in a later post.

Interesting CI / test distribution strategy

From: the hudson user list

In order to split our build across multiple servers, we have implemented a JUnit "PartitionedSuite" class. When we run our build in maven, we say -Dtest=PartitionedSuite and we pass in an "x/y" parameter like "2/5" or "1/5". The "PartitionedSuite" class scans the classpath for JUnit test classes and puts them in "y" buckets based on the hash of the Test Class name, and then only executes the Tests in bucket number "x". This way, we just define the "x/y" parameter as a per-server variable, and execute the build on y servers, and each server runs one "Partition" of Tests.

Strategies for managing many small maven2 and hudson projects

So you finally decided to structure your maven2 projects properly, e.g. identify the correct set of plugin versions/configurations that work well in your environment, introduce a set of corporate POMs.... You also decided to clean up your hudson usage, use new plugins, etc...

You have to change many POMs, probably adapt hudson projects as well. You don't want to change all those configurations one by one. The good news is that both maven and hudson use XML as storage for the config files.

Here are some tips and tools you might want to use:

Building python projects on eapps.com

Eapps.com VPS currently use CentOs 5.2 and python 2.4. Here's my worklog for getting python2.6 projects to build with nose on my hudson server hosted by eapps.com.

Here's the result:

Tips for autodeploying J2EE apps on Unix platforms

With a little bit of configuration you can have a nice autodeployment setup to save you time and remove potential errors.

For example this is something I can usually do after spending a few hours on the development infrastructure:

# from the build server, deploy the latest build for the specified project onto the 3 dev servers
deploy_build projectName trunk latest dev1 dev2 dev3

# deploy specified build for specified project
deploy_build projectName trunk build65 dev4

# deploy latest branch 2.0 onto specified server
deploy_build projectName 2.0 latest dev5

Also with a little bit more glue code those same commands can be run through your CI server interface, allowing one click deployment from the CI server GUI.

This is one way of achieving it, using standard Unix tools.

Hudson, maven and git on eapps.com VPS

VPS hosting from eapps.com is a reasonable compromise between cost and hosting service quality. I use it to host a hudson CI server.

This entry explains how I set it up up to a point where I can build using maven a java project hosted on a ssh protected git repository (on github). I will not go into the hudson specific stuff, the hudson wiki is usually complete & well worded. But I will spend more time on the OS specific stuff such as daemon configuration, ssh specifics, etc...