Is there a Maven plugin that allows you to check if there are newer versions of dependencies available in the repository?
Say, you are using dependency X with version 1.2. Now a new version of X is released with version 1.3. I'd like to know, based on the dependencies used in my project, which dependencies have newer versions available.
The Maven Versions plugin and it's display-dependency-updates mojo are what you're looking for:
mvn versions:display-dependency-updates
Here is what the output looks like:
[INFO] ------------------------------------------------------------------------
[INFO] Building Build Helper Maven Plugin
[INFO] task-segment: [versions:display-dependency-updates]
[INFO] ------------------------------------------------------------------------
[INFO] [versions:display-dependency-updates]
[INFO]
[INFO] The following dependency updates are available:
[INFO] org.apache.maven:maven-artifact ........................ 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-plugin-api ...................... 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-project ....................... 2.0.2 -> 2.0.9
[INFO] org.codehaus.plexus:plexus-utils ....................... 1.1 -> 1.5.6
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri Aug 15 10:46:03 IST 2008
[INFO] Final Memory: 10M/167M
[INFO] ------------------------------------------------------------------------
If you want to receive email notifications when newer artifacts versions are available on Maven Central you can create an account on artifact-listener and choose which artifact you want to follow.
You can either search manually for artifacts or directly upload your pom.xml.
You will periodically received notifications like this one (available in english and french for now) :
In projects with a large number of dependancies, you sometimes keep your versions in a properties section.
<properties>
<assertj.version>3.15.0</assertj.version>
<aws-sdk.version>1.11.763</aws-sdk.version>
<cxf.version>3.3.6</cxf.version>
In the case where you are only interested in updates to those versions, you can use the following command
mvn versions:display-property-updates
This gives a more condensed view and only returns the versions you need to update in the properties section.
The VersionEye Maven Plugin is doing the same: versioneye_maven_plugin.
VersionEye can notify you about new versions on Maven Repositories, too. It is a language agnostic tool and beside Java it supports 7 other languages. Beside the simple follow/notify feature it can also directly monitor GitHub and BitBucket repositories and notify your about out-dated dependencies in your projects.
There is also a REST JSON API, for tool integrations.
By the way, I'm the dude who started this project. Let me know if you have questions.
The ideal way to do it is to set dependency versions as properties in pom.xml and then running the below command to get the updated versions for your specific/custom dependencies.
<properties>
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<skip.tests>true</skip.tests>
<spring-cloud-gcp.version>1.2.3.RELEASE</spring-cloud-gcp.version>
<spring-cloud.version>Hoxton.SR6</spring-cloud.version>
<spring-cloud-stream-schema.version>2.2.1.RELEASE</spring-cloud-stream-schema.version>
<confluent.version>5.5.1</confluent.version>
<avro.version>1.10.0</avro.version>
<janino.version>3.1.2</janino.version>
<swagger.version>2.9.2</swagger.version>
<google-cloud-logging-logback.version>0.118.1-alpha</google-cloud-logging-logback.version>
<spring-cloud-stream-binder-kafka.version>3.0.6.RELEASE</spring-cloud-stream-binder-kafka.version>
</properties>
mvn versions:display-property-updates
[INFO] The following version properties are referencing the newest available version:
[INFO] ${avro.version} .............................................. 1.10.0
[INFO] ${spring-cloud-stream-schema.version} ................. 2.2.1.RELEASE
[INFO] ${janino.version} ............................................. 3.1.2
[INFO] The following version property updates are available:
[INFO] ${spring-cloud-gcp.version} .......... 1.2.3.RELEASE -> 1.2.5.RELEASE
[INFO] ${google-cloud-logging-logback.version} 0.118.1-alpha -> 0.118.2-alpha
[INFO] ${spring-cloud-stream-binder-kafka.version} 3.0.6.RELEASE -> 3.0.8.RELEASE
[INFO] ${confluent.version} ................................. 5.5.1 -> 6.0.0
[INFO] ${swagger.version} ................................... 2.9.2 -> 3.0.0
[INFO] ${spring-cloud.version} .................... Hoxton.SR6 -> Hoxton.SR8
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.572 s
[INFO] Finished at: 2020-10-06T09:35:08-07:00
[INFO] ------------------------------------------------------------------------
Another way to achieve this is by executing the command mvn versions:display-dependency-updates but the problem I face with this approach is that it also shows me updates for the nested dependencies which are not too useful for me.
You can use the Versions Maven Plugin[1] to generate reports in your Maven site to get a list of possible updates. With regard to Spring's irregularity, it appears to use the Mercury versioning system[2]. When configuring the Versions plugin, you can add a special rule for Spring stuff:
http://mojo.codehaus.org/versions-maven-plugin/
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges
I might be a bit late to join the party but a more clear way to get more readable html file or a xml file as report which can be taken for further automation using:
mvn versions:dependency-updates-report
This report plugin not just shows more comprehensive details on updates but also has options to update to latest versions. You can find the documentation for it to use various parameters.
You can use Maven Check, a command line tool, which is standalone unlike the Versions Maven Plugin. It also works with Gradle projects.
Output example:
2 build file(s) found, checking for artifact updates
my-gradle-project\build.gradle
[COMPILE ONLY] com.google.guava:guava 31.0-android -> 31.1-android
1 artifact update(s) available
my-maven-project\pom.xml
[DEPENDENCY] org.apache.commons:commons-lang3 3.10 -> 3.12.0
[BUILD PLUGIN] org.apache.maven.plugins:maven-compiler-plugin 3.10.0 -> 3.10.1
2 artifact update(s) available
2/2 build file(s) checked, 3 artifact update(s) available
Disclaimer: I am the author of Maven Check.
Related
I've got a Jenkins/maven build where we need to be able to produce release artifacts with arbitrary version numbers. The version number is passed in as a parameter to the build job. I'm using versions:set to update the version from what is in the pom.xml to the $VERSION parameter. When the build is run, it appears that maven does in fact update the version in the working copy of the pom.xml, however it builds the artifact with the old version number.
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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<name>someservice</name>
<groupId>com.domain.group</groupId>
<artifactId>someservice</artifactId>
<version>1.0.0-SNAPSHOT</version>
Invoke top-level maven targets in Jenkins job:
-V
-B
-e
-U
clean
versions:set
-DnewVersion=${VERSION}
package
deploy
-Dmaven.test.skip=true
My build output looks something like this (with a $VERSION of 0.1.2)
[INFO] ------------------------------------------------------------------------
[INFO] Building someservice 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.2:set (default-cli) # someservice ---
[INFO] Searching for local aggregator root...
[INFO] Local aggregation root: /svn/group/someservice/trunk
[INFO] Processing change of com.domain.group:someservice:1.0.0-SNAPSHOT -> 0.1.2
[INFO] Processing com.domain.group:someservice
[INFO] Updating project com.domain.group:someservice
[INFO] from version 1.0.0-SNAPSHOT to 0.1.2
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.147s
[INFO] Finished at: Wed May 20 11:40:46 PDT 2015
[INFO] Final Memory: 10M/180M
[INFO] ------------------------------------------------------------------------
I've noticed that while the initial run will build with the old version, if the working dir is not reverted, subsequent runs will correctly build with the new version in the updated pom.xml. How can I get the pom file updated with the new version before the artifacts are built?
Constraints:
While it may be possible for us to have changes made to the pom.xml, it's not directly under our control and is a less practical solution. In an ideal world the pom would already be updated with the correct version and we wouldn't be doing this at all.
I know I can just add a shell step prior to the maven build and do a sed replace on pom.xml or something similar. That does work, but it's ugly and won't scale well with more complex poms. A native maven solution is greatly preferred.
I've tested this independently of jenkins, (i.e. mvn versions:set -DnewVersion=0.1.2) and the behavior is the same
What you want to achieve is not possible with current maven versions, as stated in the Usage section of the versions-maven-plugin:
Maven 2.0, 2.1, 2.2 and 3.0 do not currently support re-reading modifications of the pom.xml within one invocation of Maven.
How about adding another build step here?
I don't know if I just hit a bug in the maven versions plugin or there is something that I'm not understanding... I am using versions:use-latest-releases to update the versions of the dependencies in the pom file, specifying not to allow major updates with -DallowMajorUpdates=false. It seems maven picks up the feature according to the output (see below), but then I does upgrade the major version of Tomcat (see below).
Note: I masked the name of the project, but the rest is verbatim.
C:\>mvn clean versions:use-latest-releases -DallowMajorUpdates=false
[INFO] Scanning for projects...
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building XXXXXXXXXXX 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) # XXXXXXXXXXX ---
[INFO]
[INFO] --- versions-maven-plugin:2.1:use-latest-releases (default-cli) # XXXXXXXXXXX ---
[INFO] Minor version changes allowed
Props: {project.version=1.0-SNAPSHOT, project.artifactId=XXXXXXX, project.groupId=xxx.xxx.xxxxxx}
[INFO] Updated org.apache.tomcat:servlet-api:jar:6.0.33 to version 7.0.0.RC3
[... more stuff ...]
Any ideas? Thanks.
I guess this is related to the version number of the servlet-api (7.0.0.RC3) which is not a maven conform version number. Maven and the version plugin expects something like this:
<major version>.<minor version>.<incremental version>-<qualifier>
Version numbers like not matching this also messes up maven version ranges. I do not know how the version number plugin does this, but maven will use String comparison for version numbers not matching the schema and so do not know anything about major and minor versions. See Project Versions.
Maybe you can fix this behavior by using rules for the version plugin and ignoring all versions starting with 7 (see Rules). I never used them so I can not provide any help with this except the documentation.
I have a Jenkins+Nexus installation, and some project there that are automated.
Jenkins deploy the sources and javadocs to nexus in the deploy phase (I am using Maven Release) -- Javadoc could be ok but I don't want to have any sources in Nexus.
I was searching and googling and I don't know how to skip this step.
Thanks a lot
Output from jenkins
[INFO] [INFO]
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) # projectA ---
[INFO] [INFO] Installing /var/lib/jenkins/jobs/MyBuild/workspace/target/checkout/MyProject/projectA/target/projectA-1227.jar to .../projectA-1227.jar
[INFO] [INFO] Installing /var/lib/jenkins/jobs/MyBuild/workspace/target/checkout/MyProject/projectA/pom.xml to .../projectA-1227.pom
[INFO] [INFO] Installing /var/lib/jenkins/jobs/MyBuild/workspace/target/checkout/MyProject/projectA/target/projectA-1227-sources.jar to .../projectA-1227-sources.jar
[INFO] [INFO] Installing /var/lib/jenkins/jobs/MyBuild/workspace/target/checkout/MyProject/projectA/target/projectA-1227-javadoc.jar to .../projectA-1227-javadoc.jar
[INFO] [INFO]
Try adding : -Darguments="-Dsource.skip=true -Dmaven.javadoc.skip=true"
to your maven release plugin config (Jenkins > your build configuration > Maven release build > Release goals and options
By default this actually does not happen automatically. Most likely you have configured a release profile somewhere in your pom hierarchy that adds the Maven Source Plugin execution.
You could remove that if you never want to use it or otherwise change the release plugin config to use a different profile or skip source creation or invoke the build with parameters to skip as Guilame has answered
I am trying to download a specific artifact (and all of its dependencies) to a machine's local repository.
It would seem that using the dependency:get goal would be the best option for this, but despite the documentation it does not seem to actually get the transitive dependencies.
Here is an example where I have tried to use dependency:get to download the spring-core jar and all of its many dependencies. You'll notice that the spring-core jar is the only thing downloaded despite the fact that this was done after cleaning the local repository.
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.2:get -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:3.0.5.RELEASE -Dtransitive=true
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.2:get (default-cli) # standalone-pom ---
Downloading: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar
Downloaded: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar (374 KB at 548.4 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.401s
[INFO] Finished at: Wed May 25 00:29:47 CDT 2011
[INFO] Final Memory: 7M/107M
[INFO] ------------------------------------------------------------------------
My questions are:
Is this a bug with the dependency:get goal?
If not, what am I doing wrong?
Are there any alternatives methods I could use to accomplish my initially stated goal?
If this is a one time or irregular occurrence for you, The simplest thing to do would be to define the dependency in a POM and run mvn package or similar to retrieve the dependency artifacts. You could also try mvn dependency:sources if you'd like to have the source jars too.
If this is something you want to do more regularly or as part of a process, you could look at using Aether directly to retrieve the dependencies for you.
Another approach if this is something you need to do regularly to manage groups of artifacts into your internal development ecosystem is to use Nexus' procurement suite to retrieve the dependencies and manage them into your repository.
You might can go with this solution
1) Download the artifact as you described (I tested with version 2.5.2)
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true
2) Download the pom (-Dpackaging=pom) of this artifact
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true -Dpackaging=pom org.apache.maven.plugins:maven-dependency-plugin:2.2:get
3) Use the downloaded pom to copy all dependencies via the dependency:copy-dependency gaol
c:\test>mvn -DoutputDirectory=C:/test/dependency -f C:/<path-to-repository>/org/springframework/spring-core/2.5.2/spring-core-2.5.2.pom dependency:copy-dependencies
You will find the dependencies (including test and optional scope!) in the created c:\test\dependency folder. To exclude test and optional scope use -DincludeScope=runtime.
You need to dynamically build some path information (e.g. path to the pom in your repository) to set up this solution and also need to bring the artifact itself together with its dependencies but it should work in a script without generating a special pom (which might be easier).
It would appear the answer to question #1 (Is this a bug with the dependency:get goal?) is yes. As of 5/25/2011 issue MDEP-308 is still unresolved.
I am fairly new to Maven and pom.xml. Is there a way I can find out which of my dependencies that are outdated, so that I can update version numbers in my pom.xml.
In other languages, for instance, Ruby has the command gem list outdated that gives me a list of dependencies (rubygems) I can update
I am using IntelliJ Idea if that can help.
You can do this with the Versions Maven Plugin. Check the following 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.
Here is a sample output (taken from the examples):
Checking for new dependency updates
The display-dependency-updates goal will check all the dependencies used in your project and display a list of those dependencies with newer versions available.
Here are some examples of what this looks like:
svn checkout http://svn.codehaus.org/mojo/trunk/mojo/build-helper-maven-plugin build-helper-maven-plugin
cd build-helper-maven-plugin
Run
mvn versions:display-dependency-updates
Which produces the following output:
[INFO] ------------------------------------------------------------------------
[INFO] Building Build Helper Maven Plugin
[INFO] task-segment: [versions:display-dependency-updates]
[INFO] ------------------------------------------------------------------------
[INFO] [versions:display-dependency-updates]
[INFO]
[INFO] The following dependency updates are available:
[INFO] org.apache.maven:maven-artifact ........................ 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-plugin-api ...................... 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-project ....................... 2.0.2 -> 2.0.9
[INFO] org.codehaus.plexus:plexus-utils ....................... 1.1 -> 1.5.6
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri Aug 15 10:46:03 IST 2008
[INFO] Final Memory: 10M/167M
[INFO] ------------------------------------------------------------------------
Pom install
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.5</version>
</plugin>
If you want to do it fast you can use www.versioneye.com site.
There you can define your project and upload project pom.xml, the site will also send you regular emails which notify you about new updates.
You can also mention which libraries do you want to check for update.
I don't know if it automatically fully sync with maven repo or not, but I always find its lib versions are update.
Update:
After 6 years the project switched off :(
So the mvn versions:display-dependency-updates seems to be the choice.
It isn't obvious what the POM dependency is for this.
For your convenience:
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.1</version>
</dependency>
and the Repository:
<repository>
<id>Codehaus Mojo</id>
<name>Codehaus Mojo</name>
<url>https://nexus.codehaus.org/content/repositories/releases/</url>
</repository>