Hudson Pro: Where’s the Maven job type?
One important difference between Hudson Open Source and Hudson Professional is how they support Maven 3.
Sonatype has developed state-of-the-art support for Maven 3 focusing on creating seamless integration between the internals of Hudson CI and Maven. Year of work on Maven 3 internals to support more efficient embedding along with our multi-year investment in bringing both JSR-330 support and GWT UI integration to Hudson CI has produced a CI system that support Maven 3 like no other on the market.
If you’ve used Hudson and Maven together in the past, you might be familiar with the Maven 2 project type that provides users with the ability to define a Maven build that is aware of a project’s POM. While we understood the motivation for a Maven-specific project type, we took our Maven support in an entirely difference direction. We created a Maven build that can be used a part of a larger freestyle build, and the reason we did this was to get away for the idea that a Maven build can only include one step, one call to a series of goals.
Sonatype found this to be more of a limitation than an advantage.
Sonatype Maven Training class available during European business hours
UPDATE :: Enrollment for this class is now closed
Due to popular request, Sonatype has decided to offer a MVN-101 training course in May during European business hours. The training course will be led by Anders Hammar of Devoteam Sweden, a certified Sonatype Training Partner.
Course details:
- MVN-101
- Tuesday May 10, 2011
- European Hours 9:00 am – 4:00 pm CEST (GMT + 02:00)
- ENROLL TODAY!
Maven Mechanics MVN-101 is the premier Java developer training course. It comprehensively covers Maven installation and configuration, explains the motivation behind Maven and gives an overview of related development tools. You will leave this Maven tutorial equipped with a full understanding of the Maven Project Object Model (POM) and a firm grasp of the underlying fundamentals of this development kit including:
- The Maven lifecycle
- Maven plugins and goals
- Multi-module Maven projects
- The contents of the Project Object Model (POM)
Learn Maven best practices this April
Two new virtual training dates have been added to the Sonatype schedule. Learn Maven best-practices from experts in the Maven community. With Sonatype training courses core Maven contributors carefully design our curriculum to cover topics from Maven basics to advanced development infrastructure design.
Registration is now closed for our April classes. Be sure to check out our May offering!
MVN-101: Maven Mechanics
- April 12, 2011
- 11am – 6pm EDT
- Enroll in MVN-101
MVN-201: Development Infrastructure Design
- April 13, 2011
- 11am – 7pm EDT
- Enroll in MVN-201
Top Ten Reasons to Move to Maven 3
I recently helped Dennis Lundberg prepare a talk for Jfokus on the top reasons why you should switch to Maven 3. When I work with customers setting up, or improving, their Maven-based development infrastructure I always recommend using Maven 3. I thought I’d share with you the top ten reasons that Dennis highlighted in his talk.
In a nutshell, Maven 3 is superior to Maven 2. While there might not be one single killer feature for most users, it’s more a matter of several bug fixes and improvements that together make it a much better tool. Depending on your use case and your preference, some of these reasons will be more compelling than others. Here’s the list.
#1. Maven 3 is the “Latest and Greatest”
Surely not the wording that you should use when selling this to your manager/boss/product owner/whatever, but when it comes to tools and frameworks many developers like knowing they are using the latest version. Maven 3.0 is where all the new work is done and where the main focus is. Maven 3 has a six week release cycle which was inspired by how things work at Eclipse. This gives you more predictability. You know that critical and serious bugs will be addressed quickly, and you’ll only need to wait a few weeks before the next official release is available.
Maven Tip: Project Directories Should Match the Artifact ID
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.
