Sometimes it is useful to have access to maven project properties like project.artifactId
or project.version
in a Jenkins job. For example you could calculate the next version number to set in a release job. Another use case I had in one of my projects lately is coping the build results to a remote directory using a shell script. For this to work I needed to inject the artifact’s name into the shell script as parameter. But how to do this if the artifact name constantly chances due to an updated version number in the pom? Luckily Jenkins provides an easy way to access this kind of information.
Mapped maven properties in Jenkins
Jenkins exposes general maven project properties as environment variables. Of corse this only works in maven build jobs, but not in freestyle jobs that execute maven goals. This feature has only been implemented a while ago and surprisingly it is not well documented yet. The following table shows a full list of how maven project properties are mapped to Jenkins environment variables:
maven project property | Jenkins environment variable |
---|---|
project.displayName | POM_DISPLAYNAME |
project.version | POM_VERSION |
project.groupId | POM_GROUPID |
project.artifactId | POM_ARTIFACTID |
project.packaging | POM_PACKAGING |
project.relativePath | POM_RELATIVEPATH |
Example usage
In my project I’m using a managed script to extract the results of a maven webstart build which are assembled as a zip archive to a remote windows share. Since I’m deploying from trunk and the version number in trunk changes frequently (after each production deployment), I need to determine the name of the archive and pass it to the script. My deploy script basically looks like this:
1DEPLOY_PATH=/mnt/webstart_deploy 2rm -rf $DEPLOY_PATH/* 3unzip target/$1 -d $DEPLOY_PATH
Now the only thing I have to do is to pass the archive’s name as a parameter to the shell script:
$POM_ARTIFACTID-$POM_VERSION.zip
.
If you’re trying this in your project: I had some trouble setting up the mount of the windows share I’m deploying to correctly. Make sure that the user that is running Jenkins has permissions to write to that directory. If you’re running Jenkins as a service, the user will be “jenkins”. The only way I could make it work in my environment was to mount the share using the jenkins user’s uid. This will make the jenkins user to the owner of the mounted directory. You also need a user in the windows domain, that has access to the shared directory:
1su root 2JENKINS_UID = id -u jenkins 3mount -t cifs -o user=<domain-user>,password=<domain-users-pw>,uid=$JENKINS_UID //remote_host/remote_dir /mnt/mount_point
An alternative for using a shell script would be to use the maven-antrun-plugin . But I personally don’t like describing this kind of steps using ant’s xml syntax.
More articles
fromBenedikt Ritter
Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Benedikt Ritter
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.