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.

Trafikanten & open data update - things are happening!

I am just back from a meeting with Trafikanten (where I met the Advisor for realtime data and the QA responsible). The meeting has been from my point of view pretty constructive. We've then spent a bit of time to better understand our needs. We've exchanged thoughts around their current data offering, the licensing, etc and came up with ideas that I think will make many people happy. I won't say much more for the moment, as I am waiting for them to actually implement the ideas we talked about, but as soon as I know more, you'll be posted. I would like again to thank Trafikanten for their time and I really wish them good luck with their changes. Exiting times!

Trafikanten: meeting on license and open data next week

A follow up after my last post on the topic of opendata/trafikanten. It seems that being constructive and open to new possibilities has some results. Trafikanten is revising their API license, in oart to be attractive to smaller actors as well. They invited me to a meeting on the 20th of January to present and discuss their new license proposal.

If you have some meaning on the topic, feel free to contact me, publicly or privately.

Publishing your signed OSS project to the Sonatype OSS repository

One thing I wanted to do was to publish the yui-runner releases to ibiblio. It's now pretty easy thanks to the Sonatype OSS repository, which will help you stage and release your repositories.

See the official Sonatype OSS Maven Repository guide.

Because of a few choices (git, scala), I ran into a few troubles or quirks that are worth noting though. Here's the outline of the procedure I picked up:

• clean up your POM as per the documentation
  
• no need yet to add sections for javadoc, pgp, release etc. They are by default included once the parent is inherited from. If you wish to test javadoc or pgp, you should then enable the sonatype-oss-release profile to your maven execution when needed.
  
• if you do add the javadoc attach-sources goal, you might ran into problems that causes the reactor to not find the project's own internal dependencies. This is because I think that particular goal forks maven. See https://github.com/lacostej/yui-runner/commit/7f15baa5a73c0da773a283800521a12d8c20a905
  
• you might want to configure the git push off by default (http://jira.codehaus.org/browse/SCM-444). This I think fits well with the staging principle of the Sonatype OSS repo. Use something like:
  

  
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-release-plugin</artifactId>
         <version>2.1</version>
         <configuration>
           <pushChanges>false</pushChanges>
         </configuration>
       </plugin>
  

  
  
• during release, you might want to add the use of the gpg agent if you don't like to enter your GPG passphrase for every module
  

  
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-gpg-plugin</artifactId>
         <version>1.1</version>
         <configuration>
           <useAgent>true</useAgent>
         </configuration>
       </plugin>
  

  
  
• the Sonatype OSS repository expects releases to have a javadoc artifact. As the maven-scala-plugin doesn't yet behave like the maven-javadoc-plugin, and doesn't produce nor attach a javadoc artifact to your build, I cheated a bit. This is of course temporary.
  
  
• Deploying will require the use of GPG signatures. This is what i did on Ubuntu 10.10 to get it working as I wanted (with a gpg-agent):
  
  
  
  1. create a signing key:
     

     
     jerome@lenovo-w510:~ $ gpg --gen-key
     jerome@lenovo-w510:~ $ gpg --list-keys
     jerome@lenovo-w510:~ $ gpg --keyserver pgp.mit.edu --send-key 576831db3ae26aaf
     

     
     
  2. install the agent:
     

     
     root@lenovo-w510:~ # apt-get install gnupg-agent
     

     
     
  3. configure the gpg-agent. Under ~/.gnupg/gpg-agent.conf, write
     

     
     pinentry-program /usr/bin/pinentry-gtk-2
     default-cache-ttl 86400
     max-cache-ttl 86400
     

     
     
  
  
  4. start the agent and copy the output in the terminal (this can be moved to your DE session startup instead later on)
     

     
     jerome@lenovo-w510:~ $ gpg-agent --daemon
     GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;
     jerome@lenovo-w510:~ $ GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;
     

     
     
  
  
• Now the release takes the form of:
  
  
  
  1. clean your directory (git status, git ignore, etc)
     
  2. mvn release:clean (optional)
     
  3. mvn release:prepare
     
  4. git push --tags && git push (if you disabled push)
     
  5. mvn release:perform
     
  6. follow the Sonatype doc for testing your staging repo and releasing it. If you run into problems, don't forget to drop your repo before releasing again.
     
  
  

yui-runner, what it's for ?

I've released the first public version of yui-runner, a small framework for automating the running of YUI javascript unit tests and reporting of their results.

See https://github.com/lacostej/yui-runner

As the main goal is to be able to run your tests from anywhere, the integration is done thanks to a JUnit runner. This means your tests will run in maven thanks to surefire or in your favorite editor.

An example project can be found under https://github.com/lacostej/yui-runner/tree/master/yui-runner-it/src/test/resources.

The project will soon be available on ibiblio, something I'll blog about.

Note: the API for yui-runner is going to change for more flexibility in selecting the URLs to load.