Demystifying the maven-release-plugin next version logic

I tried to determine the algorithm that the maven release plugin uses to update the release number for one of my projects.  I didn’t have much luck with google to find out how the update works.   I didn’t want to experiement with by build server since release process also created source control tags, and publishes the build to a maven repo.

Turns out with a little groovy script you can get at the versioning implementation the plugin uses.  You can give it a version, and get back what the next release version is, and what the next snapshot version will be.    This can all be done outside of the build process and outside of running the plugin.  Here is the script

@Grapes(
 @Grab(group='org.apache.maven.release', module='maven-release-manager', version='2.5.3')
)

import org.apache.maven.shared.release.versions.DefaultVersionInfo

check('1.2.3-qualifier-1-SNAPSHOT')

def check(versionStr) {
 def version = new DefaultVersionInfo(versionStr)
 def nextVersion = version.getNextVersion()
 println ""
 println "Current ${version} digits=${version.digits} ann=${version.annotation} annrev=${version.annotationRevision}"
 println " getReleaseVersionString ${version.getReleaseVersionString()}"
 println " getNextVersion ${version.getNextVersion()}"
 println " getReleaseVersionString ${nextVersion.getReleaseVersionString()}"
 println " getNextVersion ${nextVersion.getNextVersion()}"
}

Which results in

Current 1.2.3-qualifier-1-SNAPSHOT digits=[1, 2, 3] ann=qualifier annrev=1
  getReleaseVersionString 1.2.3-qualifier-1
  getNextVersion 1.2.3-qualifier-2-SNAPSHOT
  getReleaseVersionString 1.2.3-qualifier-2
  getNextVersion 1.2.3-qualifier-3-SNAPSHOT

Jetty-maven-plugin and locked files

I spent quite a bit of time trying to convince jetty started by the jetty-maven-plugin to not lock the non-jsp files in my web application.  There are a few solutions out there, but since was launching from maven I couldn’t get tweak the jetty jar, nor could I get any of the customized webdefault.xml changes to work.  Probably related to trying to apply fixes for a specific version of jetty and or the plugin to a different version of jetty and the plugin.

Anyways the fix was easy, switch to the tomcat-maven-plugin, it doesn’t lock the files by default.

‘javax.servlet.ServletException: non-HTTP request or response’ from serlvet deployed to JBOSS

It appears JBOSS doesn’t like seeing a servlet-api jar deployed in the WAR.  I assume that this is because servlet-api is just a jar to compile against, and JBOSS has it’s own implementation.  Turns out the change was simple (once you know how).  From the POM change the dependency scope from compile to provided.

Specifically from this:

    <dependency>
    	<groupId>javax.servlet</groupId>
    	<artifactId>servlet-api</artifactId>
    	<version>2.5</version>
    	<type>jar</type>
    	<scope>compile</scope>
    </dependency></pre>

To this:

    <dependency>
    	<groupId>javax.servlet</groupId>
    	<artifactId>servlet-api</artifactId>
    	<version>2.5</version>
    	<type>jar</type>
    	<scope>provided</scope>
    </dependency>

This tells maven to use the jar to compile against, but don’t include it in the war file.

Use maven to check for dependencies that are not used

Another handy mvn command.  This one will tell you if there are any dependencies you are referencing that you are not actually using in your code:

mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze

Use maven to check for dependency updates

A handy mvn command.  This one checks your POM dependencies to see if there are any newer versions of components you are using:

mvn versions:display-dependency-updates

mvn tomcat:deploy to Tomcat 7

The mvn plug-in tomcat-maven-plugin works fine with tomcat 5.5, but it gives a 403 error when you try to deploy to a tomcat 7 instance.  Turns out tomcat 7 changed the urls for deploying, so you need to configure the plugin to use this different url.  You can do this with the following plugin configuration:

<plugin> 
   <groupId>org.codehaus.mojo</groupId> 
   <artifactId>tomcat-maven-plugin</artifactId> 
   <configuration> 
      <url>http://localhost:8080/manager/html</url> 
   </configuration> 
</plugin>

The magic is in the URL setting that now uses /manager/html, rather than the default url of just /manager.  The original source for this information: http://www.jroller.com/Fabszn/entry/tomcat_7_et_le_plugin