Develop Reference

Maven versioning using git branches

This question is for getting feedback on a suggested versioning system for a multi-module java application built using Maven.
We have developed a multi-jar system (micro-services) with about 15 modules/jars. Some of them (5) are libraries used by the other modules in the system but not outside of the system. The modules are all stored in separate git repositories.
We have released first version and need to get serious with branching/versioning.
Goal: Minimize work needed to be done regarding versioning (updating version numbers, manual merge because of different version information per branch, etc).
How: Modules are identified by module name and git branch name, not by module name and version
We build our own "version-files" saved as resources in each module. These contain build time, git commit-id, branch name, build URL, etc, for the module itself plus included modules. So we have no need for any Maven version number after deployment.
Note: For library modules outside the system we use standard approach both for internally developed and externally developed modules. Ie. strict numbered versioning using Maven dependency system.
The system I'm contemplating is to
always use the version number <branch-name>-SNAPSHOTin the pom files, plus configuring Maven to always fetch latest SNAPSHOT version (not only daily as it does by default - ref. What exactly is a Maven Snapshot and why do we need it?).
Use a BOM (ref. Maven BOM [Bill Of Materials] Dependency) to define dependencies.
The pom file for a module in this system will be similar to:
<project>
...
<version>${revision}</version>
<dependencies>
<dependency>
<groupId>mygroup</groupId>
<artifactId>bom</artifactId>
<version>${revision}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
<properties>
<revision>default_version</revision>
<properties>
</project>
This version is specified during build by executing mvn using similar to: mvn deploy -Drevision=<branch-name>-SNAPSHOT (ref: https://maven.apache.org/maven-ci-friendly.html).
As the pom shows, we will (mostly) have one BOM version per branch name used in the system, with version name <branch-name>-SNAPSHOT - same as the module itself. The BOM file should include dependencies using explicit versions, also for system internal modules.
Example flows:
A simple feature branch. In branch modify pom so the BOM reference refer to same as parent branch - replace ${revision} for the BOM reference. Ie. you don't need a separate BOM (yet...)
A simple feature branch for internal library. Same as previous, but you should probably create same branch for a module using this library and a same branch for BOM ensuring the two modules are linked.
A system release. Create a release branch on all modules (git repositories). Including the BOM module. E.g: release201810. In BOM file in branch release201810 ensure that all referenced system-internal modules are referred to using version release201810-SNAPSHOT.
Parallell development. Create custom branch on modules as needed. Update the custom BOM as modules are branched for this development.
Is this a good idea?

I have some concerns:
You usually put the whole multi-module project into one git repository. Then you branch on the whole project, not on single modules.
The whole project usually has a version number in x.y.z-SNAPSHOT form which is increased over the time. Releases should be built with release versions, while during development you can have SNAPSHOT versions.
It is possible to build branches as x.y.z-branchname-SNAPSHOT, but dropping the version number all together is very non-standard.
I must say that every time I deviated from the standard (for good reasons, like legacy structures in the company), it caused problems later.

Maven dependency download not checking change [duplicate]

I am a bit confused about the meaning of a Maven Snapshot and why we build one?

A snapshot version in Maven is one that has not been released.
The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It's basically "1.0 under development". This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).
The difference between a "real" version and a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday or tomorrow.
Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.

The three others answers provide you a good vision of what a -SNAPSHOT version is. I just wanted to add some information regarding the behavior of Maven when it finds a SNAPSHOT dependency.
When you build an application, Maven will search for dependencies in the local repository. If a stable version is not found there, it will search the remote repositories (defined in settings.xml or pom.xml) to retrieve this dependency. Then, it will copy it into the local repository, to make it available for the next builds.
For example, a foo-1.0.jar library is considered as a stable version, and if Maven finds it in the local repository, it will use this one for the current build.
Now, if you need a foo-1.0-SNAPSHOT.jar library, Maven will know that this version is not stable and is subject to changes. That's why Maven will try to find a newer version in the remote repositories, even if a version of this library is found on the local repository. However, this check is made only once per day. That means that if you have a foo-1.0-20110506.110000-1.jar (i.e. this library has been generated on 2011/05/06 at 11:00:00) in your local repository, and if you run the Maven build again the same day, Maven will not check the repositories for a newer version.
Maven provides you a way to change this update policy in your repository definition:
<repository>
<id>foo-repository</id>
<url>...</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>XXX</updatePolicy>
</snapshots>
</repository>
where XXX can be:
always: Maven will check for a newer version on every build;
daily, the default value;
interval:XXX: an interval in minutes (XXX)
never: Maven will never try to retrieve another version. It will do that only if it doesn't exist locally. With the configuration, SNAPSHOT version will be handled as the stable libraries.
(model of the settings.xml can be found here)

The "SNAPSHOT" term means that the build is a snapshot of your code at a given time.
It usually means that this version is still under heavy development.
When the code is ready and it is time to release it, you will want to change the version listed in the POM. Then instead of having a "SNAPSHOT" you would use a label like "1.0".
For some help with versioning, check out the Semantic Versioning specification.

A "release" is the final build for a version which does not change.
A "snapshot" is a build which can be replaced by another build which has the same name. It implies that the build could change at any time and is still under active development.
You have different artifacts for different builds based on the same code. E.g. you might have one with debugging and one without. One for Java 5.0 and one for Java 6. Generally its simpler to have one build which does everything you need. ;)

Maven versions can contain a string literal "SNAPSHOT" to signify that a project is currently under active development.
For example, if your project has a version of “1.0-SNAPSHOT” and you deploy this project’s artifacts to a Maven repository,
Maven would expand this version to “1.0-20080207-230803-1” if you were to
deploy a release at 11:08 PM on February 7th, 2008 UTC. In other words, when you
deploy a snapshot, you are not making a release of a software component; you are
releasing a snapshot of a component at a specific time.
So mainly snapshot versions are used for projects under active development.
If your project depends on a software component that is under active development,
you can depend on a snapshot release, and Maven will periodically attempt
to download the latest snapshot from a repository when you run a build. Similarly, if
the next release of your system is going to have a version “1.8,” your project would
have a “1.8-SNAPSHOT” version until it was formally released.
For example , the following dependency would always download the latest 1.8 development JAR of spring:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>1.8-SNAPSHOT”</version>
</dependency>
Maven
An example of maven release process

I'd like to make a point about terminology. The other answers gave good explanations about what a "snapshot" version is in the context of Maven. But does it follow that a non-snapshot version should be termed a "release" version?
There is some tension between the semantic versioning idea of a "release" version, which would seem to be any version that does not have a qualifier such as -SNAPSHOT but also does not have a qualifier such as -beta.4; and Maven's idea idea of a "release" version, which only seems to include the absence of -SNAPSHOT.
In other words, there is a semantic ambiguity of whether "release" means "we can release it to Maven Central" or "the software is in its final release to the public". We could consider -beta.4 to be a "release" version if we release it to the public, but it's not a "final release". Semantic versioning clearly says that something like -beta.4 is a "pre-release" version, so it wouldn't make sense for it to be called a "release" version, even without -SNAPSHOT. In fact by definition even -rc.5 is a release candidate, not an actual release, even though we may allow public access for testing.
So Maven notwithstanding, in my opinion it seems more appropriate only to call a "release" version one that doesn't have any qualifier at all, not even -beta.4. Perhaps a better name for a Maven non-snapshot version would be a "stable" version (inspired by another answer). Thus we would have:
1.2.3-beta.4-SNAPSHOT: A snapshot version of a pre-release version.
1.2.3-SNAPSHOT: A snapshot version of a release version.
1.2.3-beta.4: A stable version of a pre-release version.
1.2.3: A release version (which is a stable, non-snapshot version, obviously).

usually in maven we have two types of builds
1)Snapshot builds
2)Release builds
snapshot builds:SNAPSHOT is the special version that indicate current deployment copy not like a regular version, maven checks the version for every build in the remote repository
so the snapshot builds are nothing but development builds.
Release builds:Release means removing the SNAPSHOT at the version for the build, these are the regular build versions.

A Maven SNAPSHOT is an artifact created by a Maven build and pretends to help developers in the software development cycle.
A SNAPSHOT is an artifact (or project build result ) that is not pretended to be used anywhere, it's only a temporarily .jar, ear, ... created to test the build process or to test new requirements that are not yet ready to go to a production environment.
After you are happy with the SNAPSHOT artifact quality, you can create a RELEASE artifact that can be used by other projects or can be deployed itself.
In your project, you can define a SNAPSHOT using the version element in the pom.xml file of Maven:
<groupId>example.project.maven</groupId>
<artifactId>MavenEclipseExample</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<description>Maven pom example</description>
If you want to understand better Maven you can look into these articles too:
https://connected2know.com/programming/menu-maven-articles/

This is how a snapshot looks like for a repository and in this case is not enabled, which means that the repository referred in here is stable and there's no need for updates.
<project>
...
<repositories>
<repository>
<id>lds-main</id>
<name>LDS Main Repo</name>
<url>http://code.lds.org/nexus/content/groups/main-repo</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</project>
Another case would be for:
<snapshots>
<enabled>true</enabled>
</snapshots>
which means that Maven will look for updates for this repository. You can also specify an interval for the updates with tag.

simply snapshot means it is the version which is not stable one.
when version includes snapshot like 1.0.0 -SNAPSHOT means it is not stable version and look for remote repository to resolve dependencies

Snapshot simply means depending on your configuration Maven will check latest changes on a special dependency. Snapshot is unstable because it is under development but if on a special project needs to has a latest changes you must configure your dependency version to snapshot version. This scenario occurs in big organizations with multiple products that these products related to each other very closely.

understanding the context of SDLC will help understand the difference between snapshot and the release. During the dev process developers all contribute their features to a baseline branch. At some point the lead thinks enough features have accumulated then he will cut a release branch from the baseline branch. Any builds prior to this time point are snapshots. Builds post to this point are releases. Be noted, release builds could change too before going to production if any defect spot during the release testing.

As the name suggests, snapshot refers to a state of project and its dependencies at that moment of time. Whenever maven finds a newer SNAPSHOT of the project, it downloads and replaces the older .jar file of the project in the local repository.
Snapshot versions are used for projects under active development. If your project depends on a software component that is under active development, you can depend on a snapshot release, and Maven will periodically attempt to download the latest snapshot from a repository when you run a build.

In development phase Maven snapshots everyday looks for newer higher version if available in nexus repository n download it locally for next build.
Four option you can set in respository defination
Always,
Daily (default),
Interval,
Never,
Note: In production release we should not have dependency on snapshot version.

The SNAPSHOT value refers to the 'latest' code along a development branch and provides no guarantee the code is stable or unchanging. Conversely, the code in a 'release' version (any version value without the suffix SNAPSHOT) is unchanging.
In other words, a SNAPSHOT version is the 'development' version before the final 'release' version. The SNAPSHOT is "older" than its release.
During the release process, a version of x.y-SNAPSHOT changes to x.y. The release process also increments the development version to x.(y+1)-SNAPSHOT. For example, version 1.0-SNAPSHOT is released as version 1.0, and the new development version is version 1.1-SNAPSHOT.

How to run Maven as if you were in the past

Is it any way to run Maven as if you were in another date?
My problem is I have a pom that worked with a large amount of "RELEASE" versions a month ago, but now some changes in the packages makes my project unable to run (support for some features has been discontinued). Unfortunately this dependencies are quite a lot and I don't know the version they were at that time, is there any way to run maven and tell to download the packages that were "RELEASE" version as of a specified date?
I'm editing because I feel I explained my problem poorly.
Assume I have the following dependency in my pom.xml
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>RELEASE</version>
</dependency>
If I run "mvn something" today it will fetch commons-io 2.4 but if I were to run two years ago it would have fetched commons-io 2.2
I'd like to run maven and tell him to fetch the package being the RELEASE version at some time in the past.

No, it's not possible to resolve versions "as if" at a particular time in the past, and for this reason it is almost always preferable to use explicit versions rather than LATEST or RELEASE.
If you have a specific date in mind, you can check Central (e.g., for commons-io) and see the latest version deployed before that date. You would then need to edit your pom to use that version.
Central has an API (e.g, those same commons-io results as JSON) which would allow you to automate this.

This might not be possible with maven,to revert the pom file as per a specific date,i think to overcome this type of problems and to have more advantages we use SVN , GIT .
Maven is just a build tool,its not like or provide any of the function for version control or can keep track for the changes in dependencies.

I don't know maven well and I'm not sure this will work, but it might give you some ideas:
1: Back up your pom.xml file (so you can recover if the following doesn't work)
2: Remove all dependancy tags in the pom.xml file.
3: Insert just the major dependancy tags for major jar files (example: hibernate or spring) (and no others) and specify their (old) versions in the tag.
4: Compile.
5: I believe maven will download the appropriate versions of any supporting jar files (such as commons-io) that those versions of hibernate and spring needs.
6: Repeat step 3 through 5 for any other major jar files after going to their web pages and seeing what version was in existance in the past that you need.

Can Maven install POM when building and artifact with classifier?

I have a Maven project, which uses JAR packaging. When I run the install phase, it will install both Project-1.0.jar and Project-1.0.pom files in my local repository.
Now I would like the JAR to be built with a classifier. This is easy enough: I just add the line to my jar plugin configuration:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>whatever</classifier>
[...]
</configuration>
</plugin>
Now, this works in that it installs Project-1.0-whatever.jar in my repo, but no longer installs a POM.
In case it matters, I want to use this feature in conjunction with profiles, i.e. I want to build JARs with different classifiers with different profiles.
The reason I want the POM is because I have other projects depending on this one. When I build one of these, it will try to find a POM for this dependency. If it can't, it will happily use the JAR, but that is not an acceptable solution for me for a couple of reasons:
It's bad enough that it will try to contact external repos and look for it, but even worse, we use a share repo, so it will download the POM from the shared repo, which may not be what I want - for example if I just made changes to the POM and am trying to test them.
Is there a solution, or can anyone suggest a reasonable workaround?
EDIT: I just discovered that the issue affects Maven 2.2.1, but not Maven 3.0.5. This may therefore be a bug or a difference in features between versions. I would still be interested in solutions/workarounds for Maven 2, as migrating the project to Maven 3 is a complicated affair and not likely to happen.

The reason turned out to be nothing to do with Maven version as such, and everything to do with the version of maven-install-plugin. It turns out versions prior to 2.3 have this bug.
Old installations of Maven are somewhat likely to suffer this issue, as Maven 2 will use any version of a plugin that it has unless a version has been explicitly specified in the POM, but maven-install-plugin is included by default and it's quite possible for a POM not to explicitly specify it at all (as it was in my case).

How do I upgrade the version of a maven plugin?

I am using the maven-ear-plugin version 2.3.1 - I know there is a new version available: http://maven.apache.org/plugins/maven-ear-plugin/
I can't work out how to upgrade to the latest version?

Even though this has already gotten the "approved answer", it turns out that there is this AWESOME versions plugin that handles the neverending version maintenance problem.
For those lazy people here are some of its goals:
versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available.
versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available.
versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available.
versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM.
versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version.
versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).
versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4
versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT.
versions:set can be used to set the project version from the command line.
versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version.
versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version.
versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version.
versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version.
versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version.
versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version.
versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version.

The default plugin versions are inherited from the Super POM, and you can check them with mvn help:effective-pom.
If you want to override the version provided there, add this to your POM:
<project>
<build>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.1</version>
</plugin>
</plugins>
</build>
</project>
Replace the version with what you need.

How the version of a plugin is selected, along with discussion about the plugin versions in the superpom is covered in detail here.
Actually the currently selected answer isn't quite right. It should be
<project>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.1</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
I explained why here:
"The regular plugins section also allows the version and default configuration to be defined, and this is where the confusion lies. It is technically valid to define the plugin version and default configuration here, but I find it easier to grok the pom when following this guideline:
If the plugin block is not defining an execution (and thus binding maven to do something in the lifecycle), put that block in pluginManagment"

Some maven plugins are restricted to maven versions. For example, generally projects around here use Maven 2.0.4, which is restricted to use the war plugin 2.0.2 - this works with overlays. The 2.1-alpha whatever, however, that Maven 2.0.9 uses, does not - so we had to manually downgrade. Maven, unless otherwise instructed, will attempt to use the latest version of a plugin that it can according to its version.