Combining the git-flow branching model and the Maven Release Plugin to play nice. Based on info found here: http://vincent.demeester.fr/2012/07/maven-release-gitflow/

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>group</groupId>
	<artifactId>dummy</artifactId>
	<name>Dummy Project</name>
	<version>1.0.12</version>
	<packaging>pom</packaging>
	<scm>
		<connection>scm:git:https://......</connection>
		<tag>HEAD</tag>
	</scm>

	<build>
		<plugins>
			...
			<plugin>
				<artifactId>maven-release-plugin</artifactId>
				<version>2.4.2</version>
				<configuration>
					<autoVersionSubmodules>true</autoVersionSubmodules>
					<!-- Keep changes in the local repo, push will be done afterwards -->
					<pushChanges>false</pushChanges>
					<localCheckout>true</localCheckout>
					<!-- Use a better name for the tag -->
					<tagNameFormat>v@{project.version}</tagNameFormat>
				</configuration>
				<dependencies>
					<dependency>
						<groupId>org.apache.maven.scm</groupId>
						<artifactId>maven-scm-provider-gitexe</artifactId>
						<version>1.9</version>
					</dependency>
				</dependencies>
			</plugin>
			...
		</plugins>
	</build>
</project>

release.sh

#!/bin/bash

# THe issue is that the Maven Release Plugin insists on creating a tag, and git-flow also wants to create a tag.
# Secondly, the Maven Release Plugin updates the version number to the next SNAPSHOT release before you can
# merge the changes into master, so you end with the SNAPSHOT version number in master, and this is highly undesired.
# This script solves this by doing changes locally, only pushing at the end.
# All git commands are fully automated, without requiring any user input.
# See the required configuration options for the Maven Release Plugin to avoid unwanted pushs.

# Based on the excellent information found here: http://vincent.demeester.fr/2012/07/maven-release-gitflow/

# CHANGE THESE BEFORE RUNNING THE SCRIPT!
# The version to be released
releaseVersion=1.0.11
# The next development version
developmentVersion=1.0.12-SNAPSHOT
# Provide an optional comment prefix, e.g. for your bug tracking system
scmCommentPrefix='GST-1234: '

# Start the release by creating a new release branch
git checkout -b release/$releaseVersion develop

# The Maven release
mvn --batch-mode release:prepare release:perform -DscmCommentPrefix="$scmCommentPrefix" -DreleaseVersion=$releaseVersion -DdevelopmentVersion=$developmentVersion

# Clean up and finish
# get back to the develop branch
git checkout develop

# merge the version back into develop
git merge --no-ff -m "$scmCommentPrefix Merge release/$releaseVersion into develop" release/$releaseVersion
# go to the master branch
git checkout master
# merge the version back into master but use the tagged version instead of the release/$releaseVersion HEAD
git merge --no-ff -m "$scmCommentPrefix Merge previous version into master to avoid the increased version number" release/$releaseVersion~1
# Removing the release branch
git branch -D release/$releaseVersion
# Get back on the develop branch
git checkout develop
# Finally push everything
git push --all && git push --tags

Nice work man!
The only thing here I don't get clear is this:
When you create a release branch, you are supposed to test and validate it before close it, and probably you will have to add fixes to it so you can re-deploy it to QA for more testing. Finally when it is approved, then you can deploy to production, therefore you can merge it to master and develop accordingly.
So, in this case, you are not giving the time to do the testing, just creating and deleting it at the same time.
I am interested in how you manage your projects using this kind of scripts for releases. Do you use master branch for QA and Production?

Thanks! Really useful.

https://github.com/qoomon/maven-branch-versioning-extension
This extension generate the version by the current branch. It will not change the pom.xml so.
Disclaimer: I am the author