In Maven, dependencies are usually set up like this:
<dependency>
<groupId>wonderful-inc</groupId>
<artifactId>dream-library</artifactId>
<version>1.2.3</version>
</dependency>
Now, if you are working with libraries that have frequent releases, constantly updating the <version> tag can be somewhat annoying. Is there any way to tell Maven to always use the latest available version (from the repository)?
NOTE:
The mentioned LATEST and RELEASE metaversions have been dropped for plugin dependencies in Maven 3 "for the sake of reproducible builds", over 6 years ago.
(They still work perfectly fine for regular dependencies.)
For plugin dependencies please refer to this Maven 3 compliant solution.
If you always want to use the newest version, Maven has two keywords you can use as an alternative to version ranges. You should use these options with care as you are no longer in control of the plugins/dependencies you are using.
When you depend on a plugin or a dependency, you can use the a version value of LATEST or RELEASE. LATEST refers to the latest released or snapshot version of a particular artifact, the most recently deployed artifact in a particular repository. RELEASE refers to the last non-snapshot release in the repository. In general, it is not a best practice to design software which depends on a non-specific version of an artifact. If you are developing software, you might want to use RELEASE or LATEST as a convenience so that you don't have to update version numbers when a new release of a third-party library is released. When you release software, you should always make sure that your project depends on specific versions to reduce the chances of your build or your project being affected by a software release not under your control. Use LATEST and RELEASE with caution, if at all.
See the POM Syntax section of the Maven book for more details. Or see this doc on Dependency Version Ranges, where:
A square bracket ( [ & ] ) means "closed" (inclusive).
A parenthesis ( ( & ) ) means "open" (exclusive).
Here's an example illustrating the various options. In the Maven repository, com.foo:my-foo has the following metadata:
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>com.foo</groupId>
<artifactId>my-foo</artifactId>
<version>2.0.0</version>
<versioning>
<release>1.1.1</release>
<versions>
<version>1.0</version>
<version>1.0.1</version>
<version>1.1</version>
<version>1.1.1</version>
<version>2.0.0</version>
</versions>
<lastUpdated>20090722140000</lastUpdated>
</versioning>
</metadata>
If a dependency on that artifact is required, you have the following options (other version ranges can be specified of course, just showing the relevant ones here):
Declare an exact version (will always resolve to 1.0.1):
<version>[1.0.1]</version>
Declare an explicit version (will always resolve to 1.0.1 unless a collision occurs, when Maven will select a matching version):
<version>1.0.1</version>
Declare a version range for all 1.x (will currently resolve to 1.1.1):
<version>[1.0.0,2.0.0)</version>
Declare an open-ended version range (will resolve to 2.0.0):
<version>[1.0.0,)</version>
Declare the version as LATEST (will resolve to 2.0.0) (removed from maven 3.x)
<version>LATEST</version>
Declare the version as RELEASE (will resolve to 1.1.1) (removed from maven 3.x):
<version>RELEASE</version>
Note that by default your own deployments will update the "latest" entry in the Maven metadata, but to update the "release" entry, you need to activate the "release-profile" from the Maven super POM. You can do this with either "-Prelease-profile" or "-DperformRelease=true"
It's worth emphasising that any approach that allows Maven to pick the dependency versions (LATEST, RELEASE, and version ranges) can leave you open to build time issues, as later versions can have different behaviour (for example the dependency plugin has previously switched a default value from true to false, with confusing results).
It is therefore generally a good idea to define exact versions in releases. As Tim's answer points out, the maven-versions-plugin is a handy tool for updating dependency versions, particularly the versions:use-latest-versions and versions:use-latest-releases goals.
Now I know this topic is old, but reading the question and the OP supplied answer it seems the Maven Versions Plugin might have actually been a better answer to his question:
In particular the following goals could be of use:
versions:use-latest-versions searches the pom for all versions
which have been a newer version and
replaces them with the latest
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: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.
The following other goals are also provided:
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: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-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:resolve-ranges finds dependencies using version ranges and
resolves the range to the specific
version being used.
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-next-versions searches the pom for all versions
which have been a newer version and
replaces them with the next version.
versions:commit removes the pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
versions:revert restores the pom.xml files from the
pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
Just thought I'd include it for any future reference.
Please take a look at this page (section "Dependency Version Ranges"). What you might want to do is something like
<version>[1.2.3,)</version>
These version ranges are implemented in Maven2.
Unlike others I think there are many reasons why you might always want the latest version. Particularly if you are doing continuous deployment (we sometimes have like 5 releases in a day) and don't want to do a multi-module project.
What I do is make Hudson/Jenkins do the following for every build:
mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true
That is I use the versions plugin and scm plugin to update the dependencies and then check it in to source control. Yes I let my CI do SCM checkins (which you have to do anyway for the maven release plugin).
You'll want to setup the versions plugin to only update what you want:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includesList>com.snaphop</includesList>
<generateBackupPoms>false</generateBackupPoms>
<allowSnapshots>true</allowSnapshots>
</configuration>
</plugin>
I use the release plugin to do the release which takes care of -SNAPSHOT and validates that there is a release version of -SNAPSHOT (which is important).
If you do what I do you will get the latest version for all snapshot builds and the latest release version for release builds. Your builds will also be reproducible.
Update
I noticed some comments asking some specifics of this workflow. I will say we don't use this method anymore and the big reason why is the maven versions plugin is buggy and in general is inherently flawed.
It is flawed because to run the versions plugin to adjust versions all the existing versions need to exist for the pom to run correctly. That is the versions plugin cannot update to the latest version of anything if it can't find the version referenced in the pom. This is actually rather annoying as we often cleanup old versions for disk space reasons.
Really you need a separate tool from maven to adjust the versions (so you don't depend on the pom file to run correctly). I have written such a tool in the the lowly language that is Bash. The script will update the versions like the version plugin and check the pom back into source control. It also runs like 100x faster than the mvn versions plugin. Unfortunately it isn't written in a manner for public usage but if people are interested I could make it so and put it in a gist or github.
Going back to workflow as some comments asked about that this is what we do:
We have 20 or so projects in their own repositories with their own jenkins jobs
When we release the maven release plugin is used. The workflow of that is covered in the plugin's documentation. The maven release plugin sort of sucks (and I'm being kind) but it does work. One day we plan on replacing this method with something more optimal.
When one of the projects gets released jenkins then runs a special job we will call the update all versions job (how jenkins knows its a release is a complicated manner in part because the maven jenkins release plugin is pretty crappy as well).
The update all versions job knows about all the 20 projects. It is actually an aggregator pom to be specific with all the projects in the modules section in dependency order. Jenkins runs our magic groovy/bash foo that will pull all the projects update the versions to the latest and then checkin the poms (again done in dependency order based on the modules section).
For each project if the pom has changed (because of a version change in some dependency) it is checked in and then we immediately ping jenkins to run the corresponding job for that project (this is to preserve build dependency order otherwise you are at the mercy of the SCM Poll scheduler).
At this point I'm of the opinion it is a good thing to have the release and auto version a separate tool from your general build anyway.
Now you might think maven sort of sucks because of the problems listed above but this actually would be fairly difficult with a build tool that does not have a declarative easy to parse extendable syntax (aka XML).
In fact we add custom XML attributes through namespaces to help hint bash/groovy scripts (e.g. don't update this version).
The dependencies syntax is located at the Dependency Version Requirement Specification documentation. Here it is is for completeness:
Dependencies' version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:
1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
[1.0]: "Hard" requirement on 1.0
(,1.0]: x <= 1.0
[1.2,1.3]: 1.2 <= x <= 1.3
[1.0,2.0): 1.0 <= x < 2.0
[1.5,): x >= 1.5
(,1.0],[1.2,): x <= 1.0 or x >= 1.2; multiple sets are comma-separated
(,1.1),(1.1,): this excludes 1.1 (for example if it is known not to
work in combination with this library)
In your case, you could do something like <version>[1.2.3,)</version>
Are you possibly depending on development versions that obviously change a lot during development?
Instead of incrementing the version of development releases, you could just use a snapshot version that you overwrite when necessary, which means you wouldn't have to change the version tag on every minor change. Something like 1.0-SNAPSHOT...
But maybe you are trying to achieve something else ;)
Who ever is using LATEST, please make sure you have -U otherwise the latest snapshot won't be pulled.
mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories
The truth is even in 3.x it still works, surprisingly the projects builds and deploys. But the LATEST/RELEASE keyword causing problems in m2e and eclipse all over the place, ALSO projects depends on the dependency which deployed through the LATEST/RELEASE fail to recognize the version.
It will also causing problem if you are try to define the version as property, and reference it else where.
So the conclusion is use the versions-maven-plugin if you can.
By the time this question was posed there were some kinks with version ranges in maven, but these have been resolved in newer versions of maven.
This article captures very well how version ranges work and best practices to better understand how maven understands versions: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855
Sometimes you don't want to use version ranges, because it seems that they are "slow" to resolve your dependencies, especially when there is continuous delivery in place and there are tons of versions - mainly during heavy development.
One workaround would be to use the versions-maven-plugin. For example, you can declare a property:
<properties>
<myname.version>1.1.1</myname.version>
</properties>
and add the versions-maven-plugin to your pom file:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<properties>
<property>
<name>myname.version</name>
<dependencies>
<dependency>
<groupId>group-id</groupId>
<artifactId>artifact-id</artifactId>
<version>latest</version>
</dependency>
</dependencies>
</property>
</properties>
</configuration>
</plugin>
</plugins>
</build>
Then, in order to update the dependency, you have to execute the goals:
mvn versions:update-properties validate
If there is a version newer than 1.1.1, it will tell you:
[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2
If you want Maven should use the latest version of a dependency, then you can use Versions Maven Plugin and how to use this plugin, Tim has already given a good answer, follow his answer.
But as a developer, I will not recommend this type of practices. WHY?
answer to why is already given by Pascal Thivent in the comment of the question
I really don't recommend this practice (nor using version ranges) for
the sake of build reproducibility. A build that starts to suddenly
fail for an unknown reason is way more annoying than updating manually
a version number.
I will recommend this type of practice:
<properties>
<spring.version>3.1.2.RELEASE</spring.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
it is easy to maintain and easy to debug. You can update your POM in no time.
MY solution in maven 3.5.4 ,use nexus, in eclipse:
<dependency>
<groupId>yilin.sheng</groupId>
<artifactId>webspherecore</artifactId>
<version>LATEST</version>
</dependency>
then in eclipse: atl + F5, and choose the force update of snapshots/release
it works for me.
Our team of developers uses Maven for building software. We have Maven local repository on our computers. The problem is that sometimes builds made from two different developer differ, because the built packages include different version of included dependencies.
This happens when version tag is not mentioned in POM.xml file for dependencies. For example:
<dependency>
<groupId>mylib-group</groupId>
<artifactId>mylib-artifact</artifactId>
</dependency>
In this case Maven gets the newest library installed locally.
To avoid this problem We installed Maven on one computer (we call Build server) and all members of our team make build on that computer.
Is there any better solution for this case?
How can I have centralized Maven local ?
First of all: if you have a dependency like
<dependency>
<groupId>mylib-group</groupId>
<artifactId>mylib-artifact</artifactId>
</dependency>
Maven will not take the latest version, but the one defined in the <dependencyManagement> section. So you get the same results on every computer (unless you have SNAPSHOT versions which might differ).
Having said that: Having a build server is generally a good idea for having a stable environment for builds.
Addendum: You can not share a Maven local repository. This repository is not thread safe and running two builds at the same time on the same local repository can have strange effects (I speak from experience).
We are a large company with about 2000 separate Java projects. For historic reasons, we do not have multi-module projects, but we would like to introduce them.
Logically, we already have "groups" of projects, i.e. someone responsible for (say) 50 projects which are closely related. This someone regularly publishes a BOM which contains recent, coherent versions of these 50 projects.
Now it would make a lot of sense to grab these 50 projects and put them into one large multi-module project. Still, it would be necessary to publish a BOM because other projects (outside our group) should have coherent versions.
So, summarised, we need a BOM that contains the versions of all 50 projects that are part of the multi-module project. I wonder what would be the "Maven way" to create such a BOM. What I can think of:
The bom is the 51st project of the multi-module project. The versions of the dependencies are set by properties in the parent pom.
The bom is generated from the information present in the multi-module project and published as side artifact (this probably requires us to write a Maven plugin for this).
What would be advisable?
We are using BOMs as well for our multi-modules projects, but we are not tying their generation or update to the build of those modules.
A BOM is only updated when our release management process completes the delivery of a built module (or group of modules): once delivered, then the BOM is updated and pushed to Nexus (stored as a 1.0-SNAPSHOT version, constantly overridden after each delivery)
The BOM is then included within our POM (for mono or multi-module projects) and use for dependency management only, meaning our projects depends on artifact without the version: the dependency management from the BOM provides with the latest delivered version of other dependent modules.
In other words, we separate the build aspect (done here with maven) from the release part: the "bills of materials" represent what has been delivered, and ensure all projects are building with versions deemed working well together (since they have been delivered into production together).
I've never seen 2K of commercial Java projects, so will base my answer on how open source works:
Libraries shouldn't be grouped by people - they should be grouped by the problems that they solve. Often open source projects have multiple libs e.g. Jackson has jackson-databind, jackson-datatype-jsr310, etc. These libs tightly relate to each and may depend on each other.
Such groups shouldn't be too big. Some projects may have 1, others - 5 or 10. 50 libs in a group sounds way too much.
It's easier if libs in a group are released all at the same time (even if only one is updated). This makes it straightforward to keep track of versions in the apps that use multiple libs from a group.
There should be no dependencies between groups! And this is probably the most important rule. Deep hierarchy of libraries that depend on each other is not acceptable because now you need to keep compatibility between many projects and libs. This just doesn't scale. Which means there will be occasional copy-paste code between libs - this is the lesser evil.
There could be some exceptions to the last rule (maybe a lib that is used everywhere) but those must keep backward compatibility of the public API until there are no projects that depend on the old API. Such libs are very hard to maintain and it's better to opensource them.
Standalone projects now can depend on libraries from the same or different groups, but because the version within the group is the same, it's easy to set it as a property just once. Alternatively:
You can look at <scope>import</scope> which allows importing <dependencyManagement> sections from other POM files like parent POMs within a group (for some reason never worked for me).
Or at xxx-all modules - a module that depends on all other modules within group and thus when you depend on it, you also depend on others transitively.
I manage a Maven POM project, that (as usual with POM projects) consists of 1 file: pom.xml. There are multiple other projects that inherit settings from this POM. The parent pom does not function as an aggregator; there are no modules defined in it.
Since the POM project has a different release cylce and version history than the projects depending on it, it seems logical to me to put it in a separate SCM repository. The idea is that an automated build job will be triggered on a commit, which can then lead to a release of the new POM to the central artifact repository (Nexus). This leads to the situation where I have a Git repo with 1 file.
Question: Is this the normal/desired way to handle source code versioning of a POM project?
A common gloal (or enterprise) parent pom is to be considered like a separated product, it's an artifact on its own, with its own lifecyle and CI job (publishing it to a Maven repository, like Nexus in your case) and as such also with its own version control repository.
Moreover, it may also not be a repository with only one single file, the essensial pom.xml file, but also provide further resources. For example, a site folder, with its site.xml file specifying an additional report or section. In case of a git repository, it should also provide a well documented README.md file.
From experience, since a global Maven parent POM is used by many different projects, it is also good to take care of its versioning and release notes. For this reasons I would suggest to have the following:
A site folder with the following site.xml configuration (as an example):
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/DECORATION/1.4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.4.0
http://maven.apache.org/xsd/decoration-1.4.0.xsd">
<body>
<menu ref="reports" />
<menu name="Release Notes">
<item name="0.0.1" href="release-notes-0.0.1.html" />
</menu>
</body>
</project>
An additional markdown folder under site providing release notes for each version. For example, form the href above, the following file will be picked up: release-notes-0.0.1.md.vm, providing information about its release, which will then end up in the Maven site of the POM.
As you can see, the repository may contain more than the single pom.xml file even for a super parent POM. Hence, it should always have its own version control (git in this case) repository.
Additional notes:
A global parent POM is normally applying the -parent suffix (e.g. maven-parent, spring-parent, hibernate-parent). Although not a standard, it's a de fact convention, recommended to follow
Preferably, follow the Maven official layout for the POM sections
From personal experience, avoid having SNAPSHOT versions: better to have multiple minor (but fixed) versions of a common parent POM rather than unstable or potentially impacting SNAPSHOT versions: it's the global parent pom, its goal is to provide governance and common minimal configuration, it should not introduce instability.
You will find a detailed solution here
Single click code-versioning (Complimenting cloud-native Architecture)
The idea is to use the maven plugin jgit-flow plugin and using Jenkins and this plugin we have created the whole pipeline to automate this process.
We have current release 1.0.0 maven project and in parallel we want to work on the 2.0.0 maven project which we would like to rewrite the code from the scratch. Should we create the release 2.0.0 as new maven project, if we create as new project it fails in eclipse as the artifacts name conflicts. Can you recommend how we should create 2.0.0 release and update to the SVN?
Below is how we defined the current project
<project >
<modelVersion>4.0.0</modelVersion>
<groupId>org.test.demo</groupId>
<artifactId>demo-rest</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>demo-rest</name>
<repositories>
....
</repositories>
<properties>
...
</properties>
<dependencies>
....
</dependencies>
</project>
Standard approach is to have separate branches when you introduce new version and also support old version.
As you are going to do complete rewrite, you don't have problems about merging code into new version branch.
But you are right, you can't work on two projects with same artifact name in same Eclipse workspace.
You have two options:
Developers will be switching workspace between projects (which make sense if you don't want them to copy code snippets from old project)
You will rename new version of the project (which also does make sense if it is complete rewrite)
Responding to question in comment:
If you need to maintain old version alongside new version, than you need to create discipline across the team to merge each fix/enhancement from 1.0.0 branch into 2.0.0 branch (if appropriate). With this approach you would have all the fixes and enhancements in the latest version. There are tools that can help with tracking merged fixes (e.g. TortoiseSVN merge feature). You can maintain even more branches this way. But the rule is that each change from older branches needs to be merged into all newer branches.
Of course name of the artifact stays and developers will need to switch workspaces or rebase branches.