If your favorite IDE is Eclipse and you use the Alias Maven Plugin you need to launch a shell from within your IDE.

This article will show you some of your options.

Options

There are a couple of interesting plugins you can choose from.

Open native Shell

The following plugins allow to open a shell window from Eclipse. This allows to move the shell to a different monitor window

• StartExplorer Eclipse Plug-in - this plugin I use most and will given further information below.
• Open extern - simple way of opening a shell (or a file explorer)

Execute Shell within a View

The following plugins allow to display the shell within an Eclipse view. While this is really integrating the shell in the IDE it does not allow to move the shell to a different screen.

• Wicked Shell
• Terminal plug-in for Eclipse - It currently supports Linux (x86 32 and 64 bit) and Mac OS X (PPC, x86 32 and 64 bit) only.

Other means to launch a Maven command

There are other ways to launch Maven command without explicitly opening a shell:

• m2e - allows to launch Maven commands without opening a shell
• Maven shell

StartExplorer configured

Start explorer is my plugin of choice since it allows to start a shell external to the IDE and it is easily configurable.

Setting the Title

To find the right shell I configure the title to show the name of the project it is launched on.

Add to the Start Shell command title ${project_name}:

cmd.exe /c start /d ${resource_path} <b>title ${project_name}</b>

Shortcut Str-Alt-#

To quickly open the shell set the short-cut Str-Alt-# to Start Shell here (in Preferences/Keys) like this:

We added a new experiment to our Alias Maven Plugin. Our theory is, that users want to add to existing aliases, e.g. to change the colour of the terminal window, to beep on failure or to quit the window on successful termination of a build process. We call this alias extension.

The extended alias is added in addition to the existing aliases so that the user may call the original or the extended version of the alias. So if an alias i is used to run a Maven install, the extension aq (read as ... and quit) adds an alias iaq that runs the install process and closes the terminal after a successful execution.

i = mvn -T 4 clean install $*
iaq = @echo off $T mvn -T 4 clean install $*  ^&^& exit $T @echo on

There is a detailed example on the web site of the Alias Maven Plugin that shows an example of using the alias extension feature.

Alias extensions are available from version 0.2.0 on.

The smartics Softlink Tool allows to automatically create links to projects on the filesystem of the project site server. This makes it easy to create URLs to projects that are easy to remember. The name of the project, i.e. the artifact ID in Maven lingo, is used as a link to the latest version.

For instance, the current site of the recode-maven-plugin project is located at

https://www.smartics.eu/de.smartics.maven.plugin/recode-maven-plugin/LATEST

This is a link to the latest version. The folder

https://www.smartics.eu/de.smartics.maven.plugin/recode-maven-plugin/{VERSION}

provides the sites for all versions, e.g.

https://www.smartics.eu/de.smartics.maven.plugin/recode-maven-plugin/0.1.4

The latest version of the project can be accessed by

http://www.smartics.eu/recode-maven-plugin/

via a softlink created by the smartics Softlink Tool.

If you want to reference a specific version, you may use the full link above or simply the shorter and more easily to remember version

http://www.smartics.eu/recode-maven-plugin/0.1.4/

The smartics Softlink Tool generates these version links, too.

Release notes help users of a product to decide, whether or not an upgrade is relevant or not. Updates usually provide new exciting features or fixes for bugs and security issues. Updates for end user products are almost always advisable (although temporary breaking plugins not compatible with the new product may be annoying), come at almost no cost and are therefore often on auto-update mode. Updates for libraries used in projects are another beast. The reason is that update costs are usually higher for libraries: API changes may require updating the project source code. The update may also introduce side effects that also call for running automated tests. Therefore project managers consider carefully when to update.

A well defined Versioning is one information to make the decision easier. The other point are the release notes. To create the release notes we use an automated process that derives the notes from Bugzilla issue management entries with help of the Issues Maven Plugin.


The configuration of the plugin in a Maven POM looks like this:

<plugin>
  <groupId>de.smartics.maven.plugin</groupId>
  <artifactId>issues-maven-plugin</artifactId>
  <configuration>
    <issueManagementUser>${bugzillaUser}</issueManagementUser>
    <issueManagementPassword>${bugzillaPassword}</issueManagementPassword>
 
    <product>${issues-product}</product>
    <component>${issues-component}</component>
  </configuration>
  <reportSets>
    <reportSet>
      <reports>
        <report>bugzilla-releasenotes-report</report>
      </reports>
    </reportSet>
  </reportSets>
</plugin>

Besides credentials to access the issues, the product and component information selects issues assigned to the given product and component (the version is derived from the version defined in the POM).

You may also add additional reports, e.g. for new-and-noteworthy changes or changes that break the API. For detailed information, please refer to the plugin's website.

Configuration in Maven POM

The automation is run with the Bugzilla Maven Plugin (please follow the link to check out the latest version and add this version to replace the ${bugzilla-maven-plugin.version} in the example below!).

<pluginManagement>
  <plugins>
    <plugin>
      <groupId>de.smartics.maven.plugin</groupId>
      <artifactId>bugzilla-maven-plugin</artifactId>
      <version>${bugzilla-maven-plugin.version}</version>
      <configuration>
        <classification>Unclassified</classification>
        <initialOwner>me@example.com</initialOwner>
      </configuration>
    </plugin>
  </plugins>
</pluginManagement>

The configuration property classification allows to assign the product to the given classification. The initialOwner property will determine the default owner of an issue if none is provided.

Also provide the URL to your Bugzilla server:

<issueManagement>
  <system>bugzilla</system>
  <url>http://....</url>
</issueManagement>

That's it for the project! All other information will be read from the POM:

• The classification is set by the property provided in the plugin's configuration.
• The name of the product: name
• Version and Milestone is derived from the version
• The project description is copied from description
• The default milestone is set to the current version (without -SNAPSHOT.
• Components are per default for a single project @Product (this is configurable, please consult the documentation of the plugin for details), the sub modules for a multi project.

Configure Maven Environment

Provide your password to login to your Bugzilla server in your settings.xml:

<server>
  <id>bugzilla</id>
  <username>username</username>
  <password>password</password>
</server>

Please consider to add the password encrypted!

<server>
  <id>bugzilla</id>
  <username>username</username>
  <password>{COQLCE6DU6GtcS5P=}</password>
</server>

For detailed information on how to do the encryptions, please refer to Password Encryption.

Run: Create Product

Simply run

mvn bugzilla:init

If you use the Alias Maven Plugin with our alias configuration config-smartics-alias, simply type

bi

So this is the output on the console, telling you that the product has been successfully synchronized:

D:\alias-maven-plugin>bi
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building alias-maven-plugin 0.1.4-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- bugzilla-maven-plugin:0.5.0:init (default-cli) @ alias-maven-plugin
--
[INFO] Successful login to Bugzilla.
[INFO] Successfully added product 'alias-maven-plugin'.
[INFO] Component '@Product' has been created.
[INFO] Version '0.1.4-SNAPSHOT' already existed.
[INFO] Milestone '0.1.4' already existed.
[INFO] Milestone '0.2.0' has been created.
[INFO] Milestone '1.0.0' has been created.
[INFO] Successful logout from Bugzilla.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.463s
[INFO] Finished at: Tue Sep 11 19:51:05 CEST 2012
[INFO] Final Memory: 14M/490M
[INFO] ------------------------------------------------------------------------
D:\alias-maven-plugin>

Run: Sync after a Release

If you have access to a Nexus server, then simply run

mvn bugzilla:sync

Again, if you use the Alias Maven Plugin with our alias configuration config-smartics-alias, simply type

b

If you do not have access to the Nexus server, the current version number is not determined automatically and therefore you are requested to provide it on the command line:

b -DreleasedVersion=2.0.0

[INFO] Successful login to Bugzilla.
[INFO] Version '2.0.0' has been created.
[INFO] Milestone '2.0.0' has been created.
[INFO] Milestone '2.1.0' has been created.
[INFO] Milestone '3.0.0' has been created.
[INFO] Successful logout from Bugzilla.

Further Information

For further information please refer to the plugin's site, especially to Best Practices and notes on usage. On the home page you will find a short example for a multi project.

If you have the plugin installed on your system, you may also consult the help from the command line. Type

mvn bugzilla:help

for a simple help and

mvn bugzilla:help -Ddetail

for more detailed help.

For more information on our versioning scheme, please refer to our post Versioning.

To check for plugin or dependency updates of a Maven project the Versions Maven Plugin has two interesting mojos:

mvn versions:display-plugin-updates
mvn versions:display-dependency-updates

Unfortunately the command line is a bit long. Cumbersome to type, not that easy to remember. Using the Alias Maven Plugin the command line can be shortened to:

pu
du

In addition to that checking a project for declaring all dependencies (that is not relying on transitive dependencies) or not declaring unused dependencies is a common task to keep the project dependencies clean. The Maven Dependency Plugin provides the analyze mojo for this:

mvn dependency:analyze

In short this would be

a

The configuration to make this work looks like this:

<group name="project-analysis">
  <comment>
    Aliases to analyze project information.
  </comment>
  <alias>
    <name>a</name>
    <command>mvn dependency:analyze</command>
    <comment>
      Analyzes the dependencies of this project and determines which are: used and declared;
      used and undeclared; unused and declared. This goal is intended to be used standalone,
      thus it always executes the test-compile phase - use the dependency:analyze-only goal
      instead when participating in the build lifecycle.
 
      <p>
        For more information please refer to the
        <a href="http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html">analyze mojo</a>.
      </p>
    </comment>
  </alias>
  <alias>
    <name>pu</name>
    <command>mvn versions:display-plugin-updates</command>
    <comment>
      Displays all plugins that have newer versions available.
      <p>
        For more information please refer to the
        <a href="http://mojo.codehaus.org/versions-maven-plugin/display-plugin-updates-mojo.html">display-plugin-updates mojo</a>.
      </p>
    </comment>
  </alias>
  <alias>
    <name>du</name>
    <command>mvn versions:display-dependency-updates</command>
    <comment>
      Displays all dependencies that have newer versions available.
      <p>
        For more information please refer to the
        <a href="http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html">display-dependency-updates mojo</a>.
      </p>
    </comment>
  </alias>
</group>

The comment elements are optional, but help teams to share information about the aliases.

And if you can’t remember all the shortcuts? Type h!

--- project-analysis
a   = mvn dependency:analyze [args]
pu  = mvn versions:display-plugin-updates [args]
du  = mvn versions:display-dependency-updates [args]

For more information please refer to the Alias Maven Plugin and (for an example configuration) config-smartics-alias.

Managing your project sites for many projects may give slow you down on every release if you want to maintain a single point of entry for the latest version of each project and a permanent link for each versioned site. Additionally you may want to have a link to the latest snapshot version, too. Every release should also provide links back to older versions, just in case a user landed on the latest version, but want to read the documentation for the version she actually employs.

Therefore you have

http://my-company.com/my-product-one

pointing to the latest version (release). But this is only a link to a folder deeper on this server.

http://my-company.com/category-a/my-product-one/LATEST
http://my-company.com/category-a/my-product-one/SNAPSHOT

pointing to the latest release and snapshot release. And you have the site for each version ever released:

http://my-company.com/category-a/my-product-one/0.1.0
http://my-company.com/category-a/my-product-one/0.1.1
http://my-company.com/category-a/my-product-one/0.1.2
http://my-company.com/category-a/my-product-one/0.1.3
http://my-company.com/category-a/my-product-one/0.2.0
http://my-company.com/category-a/my-product-one/0.2.1
http://my-company.com/category-a/my-product-one/0.2.2
...
http://my-company.com/category-a/my-product-one/1.0.0
...
http://my-company.com/category-a/my-product-one/2.0.0
...
http://my-company.com/category-a/my-product-one/4.23.42

And within each version you have links to the previous versions:

http://my-company.com/category-a/my-product-one/0.1.1/../0.1.0
http://my-company.com/category-a/my-product-one/0.1.2/../0.1.0
http://my-company.com/category-a/my-product-one/0.1.2/../0.1.1
http://my-company.com/category-a/my-product-one/0.1.3/../0.1.0
http://my-company.com/category-a/my-product-one/0.1.3/../0.1.1
http://my-company.com/category-a/my-product-one/0.1.3/../0.1.2
...

Creating the links manually will soon get very unproductive. So we automated this process by creating our smartics Softlink Tool. You may use it to run over your project folder once or start a demon that watches you project folder for any changes.

Today I used some simple aliases a colleague of mine added to the set of aliases of our project with the Alias Maven Plugin. Although the shortcuts seemed rather simple and negligible at first glance

rpr

instead of

mvn -T 4 release:prepare

they proofed astonishing useful. I was even so bold to run

r

instead of

mvn -T 4 release:prepare release:perform

For those of you who are not familiar with our alias plugin who may ask: "But how should I remember all those aliases?": Simply type

h

in your console.

 --- project-release
 r   = mvn -T 4 release:prepare release:perform [args]
 rpr = mvn -T 4 release:prepare [args]
 rpe = mvn -T 4 release:perform [args]
 rc  = mvn release:rollback [args]
 rc  = mvn release:clean [args]

The Alias Maven Plugin allows to specify aliases with their documentation as an XML file and generate alias scripts to various (two actually ;-): windows and bash) platforms.

You can find this configuration (with some other aliases) at config-smartics-alias.

Have a look and tell us, what you think -- if you like!

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.

We find it useful to define a versioning for our project and document it. Users of our products may then extract information about changes simply by comparing version numbers and look them up in the release reports or on our issue tracking server.

Release information provided by a Bugzilla server can be easily added with the use of our Issues Maven Plugin.

The administration of versions and milestones on a Bugzilla server can be done very conveniently with the Bugzilla Maven Plugin. Please have a look at the best practices on using this plugin.

Versioning Rules

Simple Versioning Scheme

We use the following versioning scheme.

The version consists of a major, a minor and a micro number (e.g. 1.23.42). For snapshot versions (current builds before a release), the qualifier SNAPSHOT is appended (e.g. 1.23.42-SNAPSHOT).

The parts of the version number have the following meaning.

Major Release Zero

For major releases with version number zero we handle the Simple Versioning Scheme less strict. The reason for this is that at the beginning of a project, the development is often experimental. Things work, some things don’t, some need small changes, some bigger ones.

To respect this evolutionary design we do not want to change the major release version until we regard the product as stable and shippable. Therefore, for projects in their major version number zero state compatible changes are reflected by changing the micro version, while changing the minor version may include new features and the removal of obsolete features. Incompatible changes are mentioned in the breaking news report.

Resources

• APR’s Version Numbering, Apache Portable Runtime (APR) Project
• Software versioning @ wikipedia
• This article was originally posted 2010 on our project website.

Hint for Maven users: The Versions Maven Plugin may proof useful in managing version numbers for multi projects.

Edit, 10/2012: There is a specification for this form of versioning called semantic versioning. This specification gives a deeper insight into the versioning scheme and its consequences than our short blog post here:

• Semantic Versioning
• Semantic Versioning -Technical Whitepaper – (PDF) OSGi Alliance
• About Versions – posted at Software Simplexity by Peter Kriens

Usually a team defines an encoding that is used for all files of a project. Sometimes there is more than one encoding, if either the project demands some specific encoding (e.g. in XML files) or a specification demands it (in the case of Java properties files).

Since the current version of Maven lacks convenient support for some encoding problems, a tool that ensures that specific files are copied with the right encoding is quite handy.

Our Recode Maven Plugin is developed for this simple task.

All code in any code-base should look like a single person typed it, no matter how many people contributed.

Rick Waldron

The reason for having one style for all written code is, that it is easier to feel home for each member of the team and concentrate on the job.

Arguments over style are pointless. There should be a style guide, and you should follow it.

Rebecca Murphey. Principles of Writing Consistent, Idiomatic JavaScript

It is also the only way to auto-format it. Auto-formatting releases the burden of manually indenting and typing spaces at the right places. It also helps you to compare changes before committing code to your favourite SCM tool.

I prefer auto-formatting over manual formatting although there are deficiencies: you cannot indent a section of your code in a way that makes it more readable. If the formatter is missing a format feature, you have to live with less readable code. But the formatters catch up quickly and not having to worry about manually formatting code is more productive and fun in my way of writing code.

Auto-formatting is one thing. Having elements in an XML file, like Maven's pom.xml, there is more to it than aligning elements and attributes. The elements should be presented in the same order. Especially for larger POM files this makes it easier to find relevant parts as the properties or dependencies. Unfortunately for this goal, the XML schema provided by the Maven team is quite lax. Laxness has its advantages, especially for casual users or small teams, but with larger teams, where you want to make things easier by providing less freedom of choice (less freedom is in some areas a surprisingly good thing), a strict XML schema is more productive. Therefore we created, based on Maven's original XML schema a strict one. Now every element is expected at one place and this expectation can be tested automatically. On writing the stict POM XML schema we guided ourselves by the documented order as shown on the Maven web site.

If you are interested, you may download and use this strict POM from our maven-strict-pom project page.

Unfortunately the strict XML schema does only warn you on validating the POM file, if the ordering does not meet the strict XML schema. So you have to fix the announced validation error in the pom.xml manually.

What goes beyond the strict schema we offer in our project is what Maven SortPom Plugin does. It allows to sort your POM according to predefined rules.

The following configuration meet the constraints defined in our strict POM schema:

<plugin>
  <groupId>com.google.code.sortpom</groupId>
  <artifactId>maven-sortpom-plugin</artifactId>
  <version>2.0.0</version>
  <dependencies>
    <dependency>
      <groupId>de.smartics.config</groupId>
      <artifactId>maven-strict-pom</artifactId>
      <version>1.1.0</version>
    </dependency>
  </dependencies>
  <configuration>
    <expandEmptyElements>false</expandEmptyElements>
    <keepBlankLines>true</keepBlankLines>
    <createBackupFile>true</createBackupFile>
    <sortOrderFile>strict-pom.xml</sortOrderFile>
  </configuration>
</plugin>

Unfortunately, if you are concerned with whitespace settings (like inside of description elements), the plugin does not preserve these spaces. But otherwise this fine plugin enables you to do auto formatting with your POM files!

Recently I tried to create DDLs with the Hibernate 3 Maven Plugin. Since I was using Hibernate 4 this did not work. Since Hibernate 4 provides support for DDL generation, the integration into a Maven plugin proofed not to be very difficult.

I wrote a quick-and-simple Hibernate 4 Maven Plugin that provides just the DDL generation I needed. Please consider it not to be a replacement for the fine hibernate3-maven-plugin! But if DDL creation is all you need for Hibernate 4, the Hibernate 4 Maven Plugin might come handy to you.

The following POM fragment shows everything the plugin is currently (version 0.1.1) capable of:

<plugin>
  <groupId>de.smartics.maven.plugin</groupId>
  <artifactId>hibernate4-maven-plugin</artifactId>
  <version>0.1.1</version>
  <executions>
    <execution>
      <id>export</id>
      <goals>
        <goal>hbm2ddl</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <unitName>jpa-unitname</unitName>
  </configuration>
</plugin>

If you pass SNAPSHOT versions of your software around, it is sometimes difficult to derive the source code version from the artifact. Usually you should produce releases (maybe alpha or beta releases), so that that the source code is tagged in your SCM. But sometimes this does, for whatever reason, not work. In these cases it would be nice, if the SCM revision number would be written to the JAR manifest automatically. This would make fiddling out the source code for a given artifact a brise.

The Buildmetadata Maven Plugin (previously called Maven Buildmetadata Plugin, but renamed due to the naming convention of the Maven team that all plugins following the naming scheme maven-xyz-plugin are developed by the them) does exactly that. If your are building JAR/EAR/WAR files with Maven the plugin fetches the version number from an SVN server (currently the only supported SCM system) and writes it to the manifest file.

Implementation-SCM-Revision-Date: 16.07.2010 18:12:57
Implementation-SCM-Revision-Number: 4223

The build.properties file, also stored in the META-INF folder, reveals this and additional information:

build.scmLocallyModified=false
build.scmRevision.date=26.08.2012 12\:10\:03
build.scmRevision.id=4223
build.scmRevision.url=scm\:svn\:https\://server/svn/product/trunk

The plugin checks, if the build uses locally modified (build.scmLocallyModified) files. If there a locally modified files, which usually indicates that the build was made on a developer station, these files are listed by their names.

This makes the task of tracking the source code by examining a binary artifact an instant success.

The buildmetadata-plugin also collects additional information like the machine the artifact has been built on, together with the operating system, Java and Maven version. Any environment information can be added to the meta data of the generated artifact. The plugin also supports a simple hook to access further information from a remote system.

As an add-on there is a report plugin that displays the build information on your Maven site. Look at the plugin's build report for an example.

So if you are looking for a tool to add information to the meta data of your artifacts, the chances are good that the Buildmetadata Maven Plugin will help you with your task.