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.

How to make incremental builds of maven project

every time I build my maven project, I get something like this: xxx-0.0.1-SNAPSHOT.jar. I'd like to have something like xxx-0.0.2-SNAPSHOT.jar, xxx-0.0.3-SNAPSHOT.jar etc, however a .jar that increments its name. I think, it can be done adding some plugin in pom.xml, but not yet figured out exactly how.
How can I do?
Thank you.

Snapshot builds are meant to be volatile, i.e. you can build 0.0.1-SNAPSHOT as often as you like and when you reference 0.0.1-SNAPSHOT, you get the newest version.
If you need versions with fixed numbers (like 0.0.1), you build releases. This can e.g. be done by using the Maven release plugin. If you apply it to your version 0.0.1-SNAPSHOT, then it builds 0.0.1 and makes a new commit to your git/svn to change the version number to 0.0.2-SNAPSHOT.
Before you decide what to do you should analyse exactly what you want to achieve with your versioning scheme.

Getting SonaType's release plugin to behave when using git. Or better alternatives?

Note: long question, so in essence: I wish to know how to release, via maven, a sanctified release of an existing project under my control. I use sonatype and its plugin at the moment, but their release plugin just won't let me push a SHA1 as a release. If ready-made solutions exist, I adopt them any day, provided you tell me how to modify my pom.xml, linked below
I have a Java project (available on GitHub and in use already) which I develop using Intellij IDEA 12.0.1 (community version) on Ubuntu 12.10, 64bit. The installed version of maven is the one bundled by my distribution (3.0.4).
The problem I have lies with the pom.xml of the project:
https://raw.github.com/fge/json-schema-validator/master/pom.xml
I followed SonaType's release guide. I have set up GPG, etc, all work OK. I can release using their plugin which, I surmise, is triggered by the following lines in pom.xml:
<parent>
<groupId>org.sonatype.oss</groupId>
<artifactId>oss-parent</artifactId>
<version>7</version>
</parent>
However, I have several problems with this plugin (but is it really that one?):
it creates garbage commits, always prefixed with [mvn-release-plugin], and I don't want that;
it clones from the developerConnection URI each time it wants to release, which is, frankly, stupid for anyone knowing how git works (a simple fetch and SHA1 compare can detect discrepancies) -- and this behaviour is all the more annoying that my net connection is poor, to put it mildly;
it asks to create a tag: I don't want that, I can create it myself, thank you very much;
it won't even let you customize the release commit message (and I want to include a shortlog in there).
Therefore, when I am ready for a release, I go through these steps:
create a tag on HEAD, called before
git cherry-pick a commit (which I know the SHA1 of) which replaces, in pom.xml, all git repository URIs to a local repository of mine, which I sync as needed;
at the shell prompt, let the plugin to its stuff so that the release get available "at large":
mvn release:clean
mvn release:prepare
mvn release:perform
git rebase before: get rid of the commit changing the git URIs, squash/reword etc so that the garbage commits disappear and that the release message contains a shortlog of changes instead;
create the real tag;
push to github.
Of course, this means that the Maven release, which I guarantee to be sound and sane, does not match the SHA1 of the equivalent version on the Github project. And I'd like to get rid of that discrepancy.
So, how do I get the Sonatype release plugin to behave? That is, how do I tell it to:
trust the local git repository instead of git cloneing from developerConnection,
not create useless commits,
let me customize the release message?
Or is there a better alternative which would allow me not to go through this cumbersome processs?
Details available on demand.

The release plugin is the "official" maven-release-plugin, not a special Sonatype version.
Check out the docs for the prepare and perform goals, especially localCheckout, pushChanges and suppressCommitBeforeTag (although I'm not sure the last one will do what you need).
If you prepare your project manually by changing to a release version and adding a tag, you might even be able to omit release:prepare and only run release:perform -DlocalCheckout=true, which (in theory ;) would build from your tag and push those artifacts to OSSRH.

How can I run unit tests with different versions of a library w/o changing it manually?

Unit test is in Java, using Maven to build & run. I can use either local jars "outside" Maven or local Maven repository.
However, I'd like to figure out a way to do this automatically somehow, without changing the pom.xml->running ->changing the pom.xml
Is there any other way except the above or creating pom.xmls which only differ in the specific library version?
(I'm using IntelliJ if that's of any use)

You could also read the version of your lib from a property, like
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsp.api.version}</version>
</dependency>
You can set this property in several ways, e.g. loading build-specific properties file.
You could even specify it as a parameter when running the build. On the command line svn, this is something like
mvn -Djsp.api.version=1.8 install
Don't know how to specify such an property when running Maven from inside IntelliJ, but I'm sure it's possible....
This approach would give you full flexibility to freely speficy the lib version for each build. But if you only have a limited number of versions you want to choose from, using profiles is probably the better way to go. Just define a profile for each version number and the always tell Maven which profile to use when you run a build.

What you are looking for is profiles in Maven with properties.
You use a property to specify the version number and you can use profiles to specify what the property actually is and then specify which profile to use when you run Maven.

Passing Maven Compiler Options From The Command-line

I am setting up several projects on a continuous integration server, some of which I don't have access to change the source code to, The server is a linux box, I am running into a problem where maven encoding needs to be changed to UTF8 to be able to compile on the box. Since I don't have access to modify the pom file, I was wondering if I can pass the compiler options as a command-line param? The project uses maven compiler 2.0 and I tried passing -Denconding=UTF8 without success.

You can use the Maven property "project.build.sourceEncoding".
So something along the lines of
mvn clean install -Dproject.build.sourceEncoding=UTF-8 should accomplish what you need.
This is equivalent of
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
in your pom.xml.
Edit: As a point of reference, there is the following link available POM Element for Source File Encoding showing the nuances between these properties for both Maven 2.0 and 3.0