Posts Tagged ‘Maven’

[Maven + Git] Releasing and Branching done right…

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:

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

Branch Description
master Contains the current development version (that will be released as next major release).

(I have an additional pu branch that is merged to master automatically when all tests have been run successfully, but that doesn’t matter for this entry)

next Contains some experimental code (that will be merged to master one day)
maint-[VERSION] Maintenance branches for every version. Just bugfixes are commited here and merged up.

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

1
git log master..maint-[VERSION]

2: Creating the maint-branch

1
2
3
git checkout master
git checkout -b maint-1.0.0
git publish-branch

3: Releasing on maint

1
2
mvn release:prepare
mvn release:perform

4: Merging maint to master

1
2
git checkout master
git merge maint-1.0.0

5: Updating the version on master

1
2
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

1
2
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)

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

8: Pushing the changes

1
git push

The result

Now there are three branches with different version numbers:

Branch Version
maint-1.0.0 1.0.1-SNAPSHOT
master 1.1.0-SNAPSHOT
next 2.0.0-SNAPSHOT

Maven: Fixing table bug for site plugin 2.1

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

Table Bug in maven-site-plugin:2.1

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:

1
2
3
table {
  float: none;
}

Splitting up your pom.xml into multiple files

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?

Return top
 
7 visitors online now
0 guests, 7 bots, 0 members
Max visitors today: 11 at 01:53 am CEST
This month: 13 at 09-05-2010 05:29 am CEST
This year: 97 at 08-05-2010 02:42 pm CEST
All time: 97 at 08-05-2010 02:42 pm CEST

Switch to our mobile site