• About
Triona Weblog

Software Development and much more

Maven SVN Revision Number Plugin + Wildfly Maven Plugin

20.03.2015 by Anton Autor

In the footer of a webpage application we want to have its version and its SVN revision number. We also want this to be done without hardcoding the number, but to update automatically with every new deployment. When the SVN Revision Number of the project changes, then it should automatically be updated on the web page too.

web page version number2

Webpage footer with versioning

First of all we need a simple properties file:

repository = ${prefix.repository}
path = ${prefix.path}
revision = ${prefix.revision}
mixedRevisions = ${prefix.mixedRevisions}
committedRevision = ${prefix.committedRevision}
committedDate = ${prefix.committedDate}
status = ${prefix.status}
specialStatus = ${prefix.specialStatus}
project_version = ${project.version}

 

This file is filled by the Maven SVN Revision Number plugin which we define in our pom.xml:

svn plugin

SVN Revision Number Maven Plugin

 

Since we do continuous integration, we also need to make sure that Hudson uses the plugin correctly, when deploying the project onto Wildfly. This is where the Wildfly Maven Plugin comes into play:

wildfly maven plugin

Wildfly Maven Plugin

 

When Hudson is now running the job, the azn.properties file is filled by Maven and put into the WAR “at the right time”. For example if in the above code we change <phase>deploy</phase> to <phase>compile</phase>, the plugin will run and everything will look fine, but the properties file that is actually put in the WAR won’t be the one that Maven has updated.
After all this is done correctly, one can simply read the properties file in JAVA from a backin bean and in our case display it on a JSF page as seen above.
A lot of time went into finding out, why the azn.properties file in the WAR is not having any revision numbers in it even though the plugin is running correctly.In conclusion we discovered, that defining the SVN Revision Number Plugin in the pom.xml is not enough. We also need to configure the wildfly maven plugin correctly, so that the azn.properties file gets filled AND packaged into the WAR.

 

Many Thanks to Daniel Holderbaum for helping with the configuration in the poms and finding  the necessary plugins.

Posted in: Development, Java, JEE, Triona Tagged: Continuous Integration, Hudson, Maven, Subversion, SVN, Wildfly
October 2023
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« Nov    

Tags

API Architecture CDI Collections Comparable Comparator Database EA Eclipse EJB Enterprise Architect Excel Hessian HTML Iteration Java Java 8 JavaEE Java EE Java Enterprise Development javascript Javascript Canvas HTML5 JEE JEE 6 JPA jQuery JSF linux Makro Map MariaDB Maven Oracle Plugins Relation relationship Richfaces Service Service Facade Set SOA Subversion Tutorial VBA XML

Recent Posts

  • Domain Driven Design und Event Storming
  • NESTJS BEYOND „HELLO WORLD“
  • Jakarta EE 9 – An upheaval with difficulties
  • Jakarta EE 9 – Ein Umbruch mit Schwierigkeiten
  • Erste Schritte mit Hibernate Spatial

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Copyright © 2023 Triona Weblog.

Impressum | Datenschutzerklärung