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:
I almost called this post a Maven “Pet Peeve”, but I’ll stick with “Tip” (and I’ll keep it brief). Here’s a new rule, and I’d really like to hear what the community thinks about this.
Here’s the rule:
Name your project’s directory after the artifactId of your project. It is much easier for everyone to quickly recognize and comprehend multi-module project structure, and it will more closely resemble the experience for developers working with IDEs.
Why do this?
Because it leads to simpler, easier to understand project structure. Some of you might be reading this and asking why we need to remind people of such an obvious rule. Others might take issue with the proposed rule, but I’ll try to detail why I think it is so important. Take the following collection of projects as an example:
Which one do you prefer? Left or right, and why?
On the one hand it is less typing for people on the command line to use simple directory names for Maven modules.
But, on the other hand, if you import these projects with m2eclipse you are going to end up with projects named after the artifactId. The same is true if you import these projects into IntelliJ.
I would suggest always opting for the option on the right. It is clearer than the alternative, and requires less hands-on investigation to track down a culprit project if you are debugging build errors.
An Important Note from Brian Fox: Naming the folder after the artifactId is critical if you expect inherited urls (scm/site) to work. It always appends the artifactId to the url as it’s inherited. And for the same reason, you want them to match what’s in the scm.
When should the code be tagged? How is the release/branch/tag process related to deployment? How should we branch during the release process? Should we branch early on in the release? Or, should we just continue on in trunk and only branch when we need to start parallel development? Who performs the release and from what machine? Do we run this plugin from Hudson?
This is a sample of some of the questions I’ve been asked by customers over the past few years, and, believe it or not, my answers are always a little less than satisfying. My stock answer to one of these questions is along the lines of: Well, Maven has a certain set of opinions about how you should manage releases, but it isn’t set in stone and there are as many variations in a project’s release process as there are corporations that code Java.
What we call “The Release Process” is seldom simply a technology problem and more than often involves process, organizational structure, and definitions of responsibilities. These are the intangibles that lead to the reality: everyone’s “Release Process” tends to be unique, especially as your projects become more important and more complex.
You’ve probably heard that Sonatype teaches a series of online Maven training classes. They are a great way to get you and your team up and running on Maven, and if you have any specific questions we also make sure to leave some space in the class to answer any questions you might have. In my experience, the students that get the most from our classes are the students that ask questions.
In this post, I answer some of the questions that came up in our last training session.
The Sonatype-enhanced distribution of Hudson included in the Sonatype Professional suite is designed to meet the demands of mission-critical software development. Sign up today for Sonatype’s upcoming webinar on Hudson Continuous Integration with Sonatype Professional.
Register for this webinar to learn how Sonatype Professional empowers teams to realize the promise of agile development through continuous integration, while reducing project risk. Sonatype webinars are free to attend, but you will need to sign up to reserve your spot.
- Date: Friday, January 28, 2011
- Time: 11:00 am Eastern Standard Time (New York, GMT-05:00)
- Presenters: Blaine Mincey, Sonatype Senior Systems Engineer & Patrick McBride, Sonatype Vice President of Product Management