How to fetch current subversion revision number and URL with maven
I make a checkout of some branch or tag from subversion repository and then build the project with maven.
Now, I'd like to get store current revision number and URL to some file. How can I do that? That is, I'd like to get revision number and URL of whatever branch/tag I have made checkout of.
I know about buildnumber-maven-plugin but I think it doesn't do this. It fetches revision number of branch that is specified in pom.xml.
Solution 1:
You could use the maven-antrun-plugin to execute svnversion.
<project>
[…]
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<configuration>
<tasks>
<exec executable="sh">
<arg value="-c"/>
<arg value="svnversion >version.txt" />
</exec>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[…]
</project>
NB: I've used sh -c
to run svnversion, so I can redirect the output to a file. I don't think that you can get the output into a property for use by the maven build.
You can use the same approach to run svn info --url
.
Solution 2:
As said already the Maven Build Number Plugin can be used to find the revision.
As for the URL: Maven Practice is to put it in the POM using the <scm>-tag. If you configure this right once and then use the appriopriate Maven plugins (maven-scm-plugin, maven-release-plugin) for branching, tagging, releasing, etc. you can be sure the <scm>-tag always contains the right url.
Solution 3:
Solution exposed by user2990242 is great for standalone (thank you for good explanation). After that, you just have to add information in the manifest.mf with maven-jar plugin (or maven-war). here a full example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<timestampFormat>{0,date,dd-MM-yyyy HH:mm:ss}</timestampFormat>
<doCheck>false</doCheck>
<doUpdate>false</doUpdate>
<providerImplementations>
<svn>javasvn</svn>
</providerImplementations>
</configuration>
<dependencies>
<dependency>
<groupId>com.google.code.maven-scm-provider-svnjava</groupId>
<artifactId>maven-scm-provider-svnjava</artifactId>
<version>2.1.1</version>
</dependency>
<dependency>
<groupId>org.tmatesoft.svnkit</groupId>
<artifactId>svnkit</artifactId>
<version>1.8.5</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
<manifestEntries>
<Implementation-Build>${buildNumber}</Implementation-Build>
<Implementation-Title>${project.name}</Implementation-Title>
<Implementation-Vendor>ENTERPRISE</Implementation-Vendor>
<Implementation-Version>${project.version}</Implementation-Version>
<Built-By>${user.name}</Built-By>
<Built-OS>${os.name}</Built-OS>
<Build-Date>${timestamp}</Build-Date>
<SCM-Revision>${buildNumber}</SCM-Revision>
</manifestEntries>
</archive>
</configuration>
</plugin>
Solution 4:
buildnumber-maven-plugin injects only current revision in your build so you're right. In order to get the URL I think that you should write a maven plugin that uses SVNKit.
Solution 5:
It seems to me that the API only supports execution of the 'svn' command and it's various parameters and switches. The problem is that in subversion, a different executable command is used to retrieve a proper detailed version number, that being 'svnversion'. Using this command, I can tell if I have a mixed version, a modified version, etc. For example:
[jim@localhost sb_rc1 993]$ svn info | grep Revision
Revision: 51159
[jim@localhost sb_rc1 994]$ svnversion
51159M
[jim@localhost sb_rc1 994]$
Guess what? 'svn info' is lying to me here. My local copy is modified from the original 51159 which is why 'svnversion' reports the version number with an M attached to it. What if I'm experimenting with a branch that contains a mixed version? 'svnversion' can handle this. 'svn info' cannot. Worse, as shown above, it will provide misleading and potentially disastrous information if, for example, I'm basing a release off of the bad info.