Hudson Pro: Where’s the Maven job type?


May 3, 2011 By Tim O'Brien

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.

Supporting Real-world Maven Builds

Why?  Consider an enterprise build – one that needs to prepare and perform a release.  In the scenario it is essential that the build process contain two separate calls to release:prepare and release:perform. It also might be essential to call out to supporting scripts or other parts of the build that might fall outside of the scope of the Maven build. In a complex build environment, Maven is often not the only build tool involved in a process. Instead of binding our users to a single Maven-specific project type, we implemented Maven support as a builder to make sure that Hudson Professional users had as much flexibility as they needed to create quality enterprise builds.

Creating a New Maven 3 Job
If you are new to Hudson Professional and you are wondering how to create a new Maven 3 build, you should follow these simple steps:

1. Create a New Job
2. Select “Build a free-style Software Project”
3. Add a Build Step and select “Invoke” Maven.

Creating a New Maven 3 Project from a Git Repository

The following video demonstrates the process for creating a new Maven 3 project from a Git repository:

Creating a New Maven 3 Project from a Subversion Repository

The following video demonstrates the process for creating a new Maven 3 project from a Subversion repository:

  • http://blog.aheritier.net/ Arnaud Héritier

    Hi,

    The fact to remove the need to have a specific job for Maven is a good thing I think, but did you succeeded to change the freestyle job to support the triggering between jobs when there are some SNAPSHOTs deps between several builds ?

    Arnaud

  • Gregory Boissinot

    In my opinion, it’s also a good idea to have removed Maven job type feature. It’s essential to give
    flexibility to add scripts that might fall outside of the scope of the
    Maven build. It’s the the most common use case in entreprise build.

    @Arnaud the triggering between jobs when there are SNAPSHOT deps is a very bad idea. It’s not the responsability of Hudson. I suggest you should not using Hudson job dependency
    for your build stage. Hudson is not a dependency manager. And avoiding to make an Hudson a Maven module

    • Philippe Jandot

      @Gregory triggering between jobs is a very useful feature to to support continuous integration. When an artifact is rebuilded after a change I don’t want to rebuild everything but only the artifacts that are on the dependency tree.