I have created some utility classes for testing purposes. Those depend on JDOM (used for XML formatting).

And JDOM itself has a dependency on jaxen:jaxen. But unfortunately the artifact deployed to Maven Central is broken (at least kind of).
To work around those issues with Jaxen use the following excludes:

      <dependency>
        <groupId>jaxen</groupId>
        <artifactId>jaxen</artifactId>
        <version>1.1.3</version>
        <!--

http://jira.codehaus.org/browse/JAXEN-217

        -->
        <exclusions>
          <exclusion>
            <groupId>maven-plugins</groupId>
            <artifactId>maven-cobertura-plugin</artifactId>
          </exclusion>
          <exclusion>
            <groupId>maven-plugins</groupId>
            <artifactId>maven-findbugs-plugin</artifactId>
          </exclusion>
        </exclusions>
      </dependency>

Installing Nexus manually is not a lot of fun. Thankfully a nice guy has created a working deb:

Repository:
http://build.discursive.com/apt/

It also configures Apache2 as proxy for the nexus instance.

The default compiler plugin configuration hides all warnings. To get all messages on the console, this configuration can be used:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>2.3.2</version>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
    <encoding>${project.build.sourceEncoding}</encoding>
    <showWarnings>true</showWarnings>
    <showDeprecation>true</showDeprecation>
    <compilerArgument>-Xlint:all</compilerArgument>
  </configuration>
</plugin>

This configuration is for example useful if you want to use “Compiler Warnings Plugin” for Jenkins/Hudson.

Maven is really awful. I hate it.

But it is by far the best tool available… Therefore I am using it for several years now. And since it is a tool one has to struggle with, I have invested a lot of time into optimizing my build environment. So I know Maven quite well now – better than I wanted…

And of course I am using Git. And I really love it. But unfortunately Git is just a second class citizen in Maven land. The basic things work, but other things don’t (like mvn release:branch).

I have created this checklist for doing a release. Just take a look and compare it with the steps you are doing. I’d like to hear some opinions and ideas for improvements.

Small scripts

I use some scripts that make my life easier:

• git-publish-branch

The setup

The version numbers

The upcoming release will be 1.0.0 (the first release for this project). Therefore no maintenance branches exist yet.

Currently the master branch is set to 1.0.0-SNAPSHOT.

The branches

Release: What has to be done

The master branch contains the latest peace of software that shall be released (that means that all bugfixes have been merged in from the maint* branches).

• Tag for the release
• Creating a new maint-* branch with updated version number
• Updating the version number for master
• Probably updated the version number for next, too

And: Of course release one version of our software…

The Checklist

1: Ensure all bugfixes have been merged into master

git log master..maint-[VERSION]

2: Creating the maint-branch

git checkout master
git checkout -b maint-1.0.0
git publish-branch

3: Releasing on maint

mvn release:prepare
mvn release:perform

4: Merging maint to master

git checkout master
git merge maint-1.0.0

5: Updating the version on master

mvn versions:set -DnewVersion=1.1.0-SNAPSHOT -DgenerateBackupPoms=false
git commit -a -m "preparing for next major release: updated version in master"

6: Merging master to next

git checkout next
git merge master

That merge has probably one merge conflict: The version in the pom.xml. Just keep the value of the next branch.

7: Updating the version for next (optional/if necessary)

mvn versions:set -DnewVersion=2.0.0-SNAPSHOT -DgenerateBackupPoms=false
git commit -a -m "preparing release: updated version in next"

8: Pushing the changes

git push

The result

Now there are three branches with different version numbers:

Some time ago a new big release for the site plugin has been done.
Unfortunately they have introduced a small bug:

The table tags now contain the alignment attribute set to “left”.

This results to some strange bugs. Take a look at that page:
http://fest.easytesting.org/javafx/maven/compile-mojo.html

Look at the background of the table. The following h3 gets resized and its background is drawn behind the table…

To fix it, just add those lines to the CSS:
[cc lang="css"]
table {
float: none;
}[/cc]

Ever had to deal with a really, really huge pom.xml? As soon as you start not only to declare the dependencies but also to add informations about the distribution (repositories, site), mailinglists or developers, the pom.xml starts to become really huge.

It is hard to find the informations you search. And it is much harder to find that revision a dependecy has changed if there is so much noise due to changes in other sections.
Many applications with huge configuration files started to convert their files into directories over the last years. Apache now has its “conf.d” directory, crontab uses “cron.d” and so on.

Why not take the same step, too? Why not split up the pom.xml into several files that are placed within a directory called “pom.d”?
So I have created a proposal for Maven 2.1.

What do you think?