I have introduced our Buildmetadata Maven Plugin in my previous post Buildmetadata. Now I want to add some bits of information about what buildmetadata is about. Every artifact published by smartics contains this information.
The manifest file contains, besides the SCM properties, the usual information you find in Java archive files (JARs):
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Build-Jdk: 1.6.0_20 Specification-Title: maven-buildmetadata-plugin Specification-Version: 1.1.1-SNAPSHOT Specification-Vendor: smartics Implementation-Title: maven-buildmetadata-plugin Implementation-Version: 1.1.1-SNAPSHOT Implementation-Vendor-Id: de.smartics.maven.plugin Implementation-Vendor: smartics Built-By: robert.reiner Built-OS: Windows 7 / amd64 / 6.1 Implementation-Date: 26.09.2010 01:49:56 Implementation-DatePattern: dd.MM.yyyy HH:mm:ss Implementation-Full-Version: 1.1.1-20100926r9401-SNAPSHOT Implementation-SCM-Revision-Date: 26.09.2010 01:45:33 Implementation-SCM-Revision-Number: 9401 Implementation-Timestamp: 1285458596530 Implementation-URL: http://www.smartics.eu/public/de.smartics.mave n.plugin/maven-buildmetadata-plugin/1.1.1-SNAPSHOT Java-Vendor: Sun Microsystems Inc. Java-Version: 1.6.0_20 Maven-Version: 2.2.1
In this case the SCM information is actually useful if you want to access the sources of the artifact. As this example shows, the sources for the snapshot artifact are located on the SVN server with revision number 9401.
The details can be found in the build.properties file that is also located in the META-INF folder of the JAR file.
#Created by maven-buildmetadata-plugin. #Sun Sep 26 01:50:03 CEST 2010 build.copyright.year=2006-2010 build.date=26.09.2010 01\:49\:56 build.date.pattern=dd.MM.yyyy HH\:mm\:ss build.host.name=Asgard build.java.compiler=HotSpot 64-Bit Server Compiler build.java.runtime.name=Java(TM) SE Runtime Environment build.java.runtime.version=1.6.0_20-b02 build.java.vendor=Sun Microsystems Inc. build.java.vm=Java HotSpot(TM) 64-Bit Server VM build.maven.execution.goals=clean, deploy, site-deploy build.maven.execution.isRoot=true build.maven.execution.profile.active.basic-user=settings.xml build.maven.execution.profile.active.nexus=settings.xml build.maven.execution.profiles.active=nexus, basic-user build.maven.version=2.2.1 build.os.arch=amd64 build.os.name=Windows 7 build.os.version=6.1 build.scmLocallyModified=false build.scmRevision.date=26.09.2010 01\:45\:33 build.scmRevision.id=9401 build.scmRevision.url=scm\:svn\:https\://www.smartics.de/svn/public/maven/maven-buildmetadata-plugin/trunk build.timestamp.millis=1285458596530 build.user=robert.reiner build.version=1.1.1-SNAPSHOT build.version.full=1.1.1-20100926r9401-SNAPSHOT build.year=2010
Here is also the URL to the SCM server for the snapshot artifact. If there is more than on SVN server around, you can stop guessing where the sources are actually located.
You also find a bit more detailed information about the runtime. But what may be especially useful is the mentioning of the profiles that have been activated during the build. In this example the profiles nexus and basic-user in the user's settings.xml were active. While this is of little value 2 years after the artifact has been deployed (since the settings.xml in a user's home directory is seldom in version control), it gives a hint at configuration information if a problem has been encountered during the development of the SNAPSHOT release.
All this information is not consulted every day. Most of the time, it is not consulted at all. But if a project encounters a problem with an artifact, information about who created it (whom may I ask questions?), at what machine/OS (encoding anyone?), with what Java version (used Java 7 instead of Java 5?) may proof helpful in desperate situations. Since the information is collected automatically and can be configured to the team's needs, you may want to give it a try.
