Showing posts with label scm. Show all posts
Showing posts with label scm. Show all posts

Sunday, June 21, 2009

Authenticating When Using the SCM Plugin

If you are using the SCM plugin with Mercurial then you will likely need to pass the username and password to it. This can be done with the following arguments to the mvn command:

"-Dusername=<username> -Dpassword=<password>"

You also can create a server element in your 'settings.xml' file (in ~/.m2) which has an id that matches the host part of the SCM url, then set the username/password in the respective elements. This'll keep you from having to put in the values on the command line again and again.

<server>
<id>www.blueleftistconstructor.com</id>
<username>rob</username>
<password>pass</password>
</server>

When using the release plugin I've always had to use this technique to 'push' the changeset from my local mercurial repo to the remote one.

Note that one unfortunate side effect here is that the HG Maven plugin WILL OUTPUT YOUR CREDENTIALS IN CLEAR TEXT!!!

This doesn't bother me all that much since I run a pretty tight ship, but if this violates your comfort level you may be out of luck as far as the release plugin goes.

Monday, July 2, 2007

Release Plugin "Dry Run"

The problem:

Running the "release:prepare" command in Maven does a number of caustic things. It will check in and tag your code in the SCM you use. It will also change the projects pom, rolling the version number up. If you have any "SNAPSHOT" dependencies it will fail.

The solution:


Maybe you want to do a "dry run" before executing a command that could muck up your SCM and pom? By "dry run" I mean the release plug in goes through the motions, but nothing is changed in the SCM, and your pom doesn't get messed up. Here is what you do:
mvn release:prepare -DdryRun
The "-DdryRun" tells the plug in to not fully perform the preparation. You will find this generates some temporary files in the project folder. These include:
  • pom.xml.next : what the projects pom looks like after the release
  • pom.xml.releaseBackup : what the pom looked like before
  • pom.xml.tag : the pom for the tagged version of project
  • release.properties : the information about the release of the project
It is not likely you want to keep these files around for too long. You can remove these file by running this command:
mvn release:clean
I recommend you use this whenever you are getting ready to release. It will save you a lot of time, because just one botched release attempt could take minutes to clean up. The dry run will take seconds to run.

Release plugin

The problem:

Your project uses some sort of Source Control Management (SCM). Being that your project is using Maven there are considerations such as project version to take into account when tagging releases of your project. You want a simple way to "release" a version of your project. Normally you would edit the POM changing to a new release version (from snapshot), then tag the release in your SCM, then change the pom version to the newest version, and finally check in the new pom. Another consideration is the dependencies you are using, you do not want to have snapshot dependencies in your "released" project.

The solution:

Maven developers quickly experienced the difficulty of rolling a version of a project. Thats why we now have the release plug in. When you are ready to do a release simply issue the command:
mvn release:prepare
This plug in makes short work to releasing a version of your project. You must have configured the SCM section of the pom. This section is used by the release plugin to know how to interact with your SCM.

Once you issue the command above you will be asked to give a tag name and the new version for the pom. You can also just hit enter to have the plug in use default values. Thats it, check your pom and you will see the new version. Check the source control and you will see the tag.