We Keep Coding

Maven project version interpolation from a property file

We are using a Maven for a while in our project and want to automate the release process little bit. we came up with the following idea so that the version will be maintained by developers or in SCM instead of in DevOps tool like jenkins/bamboo.
Anyone following below process instead of setting the interpolation value in arguments as "mvn install -Dapp.version=1.0.0-SNAPSHOPT"
The process we like to follow is to supply the Maven project version through an external property file.
let's assume the following partial POM.xml excerpt as example.
<project>
<groupId>com.home.diary</groupId>
<artifactId>journal</artifactId>
<version>${app.version}</version>
<packaging>war</packaging>
</project>
let's assume i have an version.properties file in my SCM with following content
app.version=2.0.0-RELEASE
while running the mvn goal
mvn install
i want the artifact generated as
journal-2.0.0-RELEASE
I tried using plugin properties-maven-plugin from org.codehaus.mojo
as discussed here How to read an external properties file in Maven
but it's not working.
Anyone did this? could you please share your implementation/ideas?

This is not possible.
First of all: Why not just manage the version in the <version> tag itself? It is the easiest thing and fulfils your requirement (the developer manages the version in the SCM).
If you don't want this, you need to supply the version either in the POM itself or through the command line. Reading external properties with something like the properties maven plugin will always happen too late, i.e. after the version tag is already read.

Which App Engine Maven Plugin to use?

been working with Google App Engine lately and stumbled upon something that is a mystery to me, maybe you can clarify.
According to some of Google's own websites (https://cloud.google.com/appengine/docs/java/tools/maven) you should use
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
and according to some other pages (https://cloud.google.com/appengine/docs/java/tools/maven-reference) you should use
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
Now I am really confused as to which I should use. Why are there two versions in the first place?
Problem I am facing:
The both seem to support different goals. One supports deploy etc. and the other one update and update_cron.
I need all 3 of those goals, any way I can have them with one dependecy?
Thanks in advance, hope someone can help me with this.
Sascha

<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
The first one is based on the previous (but not deprecated) appcfg (or Java SDK).
It offers a lot of Goals specific for App Engine, the basic ones with the dev-server and the deploy, but also for update queues, update cron, update indexes, vacuum indexes, ...
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
It's the newest one, still in beta. It is based on GCloud SDK and has a limited set of goals.
Here you can see the latest version from Maven Central, the latest one is 1.0.0, I don't see the 1.1.0-beta version
How to choose the proper plugin:
If you only need to use dev-server and deploy you can use the newest plugin based on GCloud SDK.
Those 2 goals are also available in the appcfg based plugin, but if you need more specific goals (like handling queue, cron, indexes, ...) are only available with this last one.
Also, the Google Cloud Endpoints goals, are only available to the appcfg one
At the end, those 2 plugin can coexists in the same project. The trick to use both of them is using the goal full path instead of the short one (source).
For example:
com.google.cloud.tools:appengine-maven-plugin:run
com.google.appengine:appengine-maven-plugin:devserver
And not
appengine:run
appengine:devserver
If you use the shorter version, Maven is unable to resolve the proper groupId (because the artifactId is the same on both plugins)
For the moment both plugins are operative and there is not trace of a deprecation about the appcfg based one.
Take me for example, I always use the deploy within the GCloud plugin (I consider it slighty better as deploy procedure compared to the appcfg one), but when I need to update cron/queues I use the goal of the previous plugin. I do not have any problem on having both on them inside my project
Remember that if you want to use the GCloud based one, you need to have GCloud installed (and configured) on your local machine.
Here is another thread which is discussing the same topic: `gcloud app deploy` vs. `appcfg.py`

The official documentation for both plugins is linked below:
com.google.appengine groupId
com.google.cloud.tools groupId
Both plugins are supported, they have the same artifactId (appengine-maven-plugin), but different goals and behave differently. I think this is another case of bad organization of a software evolution by Google. They could simply keep a single plugin and transparently move from one SDK to another by checking their existence in the environment, posting warnings/recommendations etc.

Precedence packagingExcludes and packagingIncludes maven war plugin

Recently I configured my application to use "skinny wars" that was described on codehaus (title: Solving the skinny war problem). Basically I exclude all jars from the war and add it as a war and pom dependency to the ear. Now I ran into a problem with two jars. So to me the logical thing to do was include them in the war file using packagingInclude.
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
<packagingIncludes>WEB-INF/lib/A.jar, WEB-INF/lib/B.jar</packagingIncludes>
</configuration>
</plugin>
Using a regex as showed in de plugin documentation and this answer but it didn't seem to do anything. It just excludes everyting.
In the source code of the plugin I found that it uses the DocumentScanner of org.codehaus.plexus » plexus-utils. I didn't quite understand how it works.
I thought this was a no brainer. But what am I doing wrong? Could it be that the inclusion doesn't work when A is also a transitive dependency of C?
Edit: Does plugin version play any role? Now I am using 2.6 but previously version 2.1-alpha-2 was used.

Found this answer as well. The following line (and only this line) works:
<packagingExcludes>%regex[WEB-INF/lib/(?!common-A|common-B).*.jar]</packagingExcludes>
Only common-A-x.x.jar and common-B-x.x.jar are in the WEB-INF/libfolder of the war file. It should be possible to extract the common part in the regex but what I tried didn't work.

try to use the includes only without the wildcard excludes definition. Since you exclude all jars this eats up your includes. As far as I understand the doc (and from my memories), the default is to include everything but as soon as you specify an include the plugin will only include your list of jars.

Checkstyle rules for Google Java Style

Is there a Checkstyle rule file with the Google Java Style?

The checkstyle team added it several days ago. Here it is :
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml

If you have a maven-project, you can easily integrate google_checks (you have to use at least maven-checkstyle-plugin version 2.17)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<configuration>
<configLocation>google_checks.xml</configLocation>
</configuration>
</plugin>
Executing checkstyle will use google_checks, e.g. do
mvn checkstyle:checkstyle
Version-background
Checkstyle-project integrates google_checks from version 6.9 on.
Maven-checkstyle-plugin version 2.17. is the first one, which is released after checkstyle6.9 (actually it uses checkstyle6.11.2). So, maven-checkstyle-plugin2.17 is the first version of this plugin, which actually ships with google_checks and provides it without any other dependency.

The Google Summer of Code project to create such a file implies, that it doesn't exist yet.

google_checks.xml comes with Checkstyle and the maven plugin.
See Google's Java Style Checkstyle Coverage,
also see Maven Checkstyle Plugin's config
Note that if you are going to customize the config based on google_checks.xml, you need to download the xml of the matching checkstyle version (on github), and modify on top of it.

Maven Plugin for project semantic versioning

I'm looking for a maven plugin that will help me manage version names and codes of every build that is made on our CI environment. Something that will be able to attach a prefix to the main version code or even update it (not changing the pom.xml). For example:
project version: 2.0.1
git/svn revision: 2342334
jar output: name-2.0.1-2342334.jar
maven repo: ../path/to/local/maven/repo/<package path>/2.0.1-2342334/
The main requirements to this plugin are:
Must be in Maven Repository (which means that NO additional setting required to add this plugin in my pom.xml and run maven)
Must not edit the pom, each time it's applied
A configuration file, would be great, so I could manage the versioning process
Must be able to edit the output file metadata (so the version will be applied as if it was written in the pom.xml file in the first place)
So far I found only maven-buildmetadata-pluging but unfortunately it's not in Maven Repo, so I'm stuck. Any help would be great.

Hosting your own maven repository is very easy, using either Nexus or Artifactory. You can also use the Artifactory cloud version (I'm not affiliated with them...) so it may solve your problem. BTW - a simple server with Apache does the trick as well, but with more work..,
Regarding the plugins: If you deploy snapshot applications then each gets its own version based on timestamp.
For releases another option is to run an svn info and put the result (or part of it) into the generated artifact. The information can then be accessed by the code.

If you change the version of your artifact the pom has to reflect the change, cause otherwise it's not reproducible.
If you change something in your build process (like added versions, whatever) it has to be reflected in the pom file. Otherwise you can not reproduce the build process with the same result.
You have written not to change the pom file but maintaining a separate file. So the questions is: Why not using the pom file itself, cause it's intended exactly for that purpose.
Furthermore all informations which you mentioned by the maven-buildmetadata-plugin can be achived by using existing maven plugins (like build-helper-maven-plugin, buildnumber-maven-plugin).
The SCM information can be used by using the buildnumber-maven-plugin which provides information like SCM revision number (SVN or GIT hash).
An on the other hand if you don't like to change your pom file manually you can use either the versions-maven-plugin or the maven-release-plugin which automatically can change informations in your pom file and handle all these things automatically.
To maintain metadata in your producted artifacts you can configure all plugins (like ear, war, jar) etc. more or less like this where the buildNumber is comming from buildnumber-maven-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin.version}</version>
<configuration>
<archive>
<addMavenDescriptor>true</addMavenDescriptor>
<index>true</index>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<artifactId>${project.artifactId}</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<buildNumber>${buildNumber}</buildNumber>
</manifestEntries>
</archive>
</configuration>
</plugin>
And of course if you really like to use Maven you should have to use an repository manager as already mentioned like Artifactory or Nexus which make life easier.

I just would like to add (although the question is 5 years old and already has an accepted answer) that the Buildmetadata Maven Plugin was not available on the Maven Repo at first, but it is now (since late 2013). People who would like to give it a try find the artifact at the following locations :
com.redhat.rcm.maven.plugin:buildmetadata-maven-plugin
de.smartics.maven.plugin:buildmetadata-maven-plugin
Please note that the name has changed from maven-buildmetadata-plugin to buildmetadata-maven-plugin due to naming conventions.
I'm one of the "original" authors of this plugin at smartics. If you would like to use it, you probably would like to use the fork provided by Red Hat. To my knowledge the two versions do not differ very much and they have not been synced since there is just so much other stuff to do and the plugin seems to be feature stable. ;-)
The source code for both versions is also available on GitHub:
release-engineering/buildmetadata-maven-plugin
smartics/buildmetadata-maven-plugin

As already stated, you have to change the version in the pom. One way of doing that, in combination with the release plugin is:
mvn \
se.bjurr.gitchangelog:git-changelog-maven-plugin:VERSION_HERE:semantic-version \
release:prepare release:perform
Using Git Changelog Maven Plugin