My prior post discussed bringing dependencies up to date with Maven. Here I’ll briefly cover Gradle. I use Gradle in my personal projects, so I looked for some of the features I depended on in Maven and found them missing. In particular, I wanted to keep track of which dependencies where out of date. With Gradle, using open ended patterns for dependency versions is much more the norm, but I still wanted to make sure those patterns were not outdated.

I did some searching, and found a variety of solutions, the closest to mavens versions plugin was a outlined in a a rather dated post from 2011. It offered a starting point at least.

Based on that post, I chose to write my own Gradle plugin. I’ve not done that before so that process was of interest too. I decided to try a Groovy plugin, which is Gradle’s core language. I’m not strong in Groovy but it’s not hard to muddle through if you’re strong in Java.


My goals were to create a plugin what would:

  • Be simple to use.
  • Understand Gradle’s dependency version patterns.
  • Do a decent job searching the available versions for newer ones.
  • Search all the repositories the build file listed.


Starting with the example of the afore mentioned post I first moved the inline code into an external plugin, and got that into Maven Central. Next I worked to improve the pattern matching, the sorting, and make it use the build files repositories. The result was vplugin and you can find the code there.


Using vplugin

To use this plugin you’ll need to add the following apply:

	apply plugin: 'com.github.nwillc.vplugin'

And modify your build file’s buildscript entry as follows:

	buildscript {
	    repositories {
		dependencies {
		        classpath 'com.github.nwillc:vplugin:1.+'

Invoking The Plugin’s Task

To invoke the vplugin task simply:

	gradle versions

What You’ll See

This plugin will produce output for your gradle project similar to:

	Searching repositories:
		MavenRepo at
		BintrayJCenter at
		maven at
	Dependency                                             Using              Update
	----------                                             -----              ------
	com.github.nwillc:almost-functional                    1.6.+ ->            1.7.7
	junit:junit                                             4.11
	org.assertj:assertj-core                               1.7.0
	com.h2database:h2                                    1.4.182
	com.github.nwillc:contracts                            1.6.2

It will show you what your dependency pattern is ends up using, and if the pattern doesn’t match the latest version it will suggest the update version.


How to bring dependencies up to date with Maven

I come to bury this task, not to praise Maven.

This post is just some pointers on how, assuming you’ve a maven project, to bring its dependencies up to date. Maven has some good tools for doing this and that’s what we’ll cover.

Preparing the pom

One thing that makes maintaining dependency versions in maven simpler is to use properties to define them.

What you’ll often find in a pom.xml is something like:


The more dependencies you have the more and more difficult finding each ones version gets. Since the versions are the most frequent thing to change a simple solution is to use properties:


Finding What’s Out of Date

Finding candidates for upgrade is in fact simple:

     mvn versions:display-dependency-updates

Will yield, amongst it chatter the following:

[INFO] The following dependencies in Dependencies have newer versions:
[INFO] .................................. 14.0 -> 18.0
[INFO]   junit:junit ...................................... 4.10 -> 4.12-beta-2

So from this output you can often simply update the properties you’ve extracted:


But you’ll note here JUnit’s newest is a beta, so that you may want to look for the last stable version and use that. If you go to the central repository’s advanced search you can look for GroupId junit, ArtifactId junit and then click the Lastest Version all and look at the version history. Maybe 4.11 is more your risk level? Some projects changed versioning schemes so you’ll get things like 20131111 -> 4.1 and at that point looking at the version history may be the only way to determine chronological order.

Don’t Trust, Verify

Simply setting the the version of a dependency does not guarantee that version is used. That may seem like a bug, but in fact maven is doing it’s level best to reconcile versions of your dependencies, and their dependencies and so on. The process and thinking on this is outside the scope of this post, but will cover some simple tactics for dealing with this.

First, as said, don’t trust, verify:

mvn dependency:tree -Dverbose

This will yield the tree of dependencies as maven sees it:

[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ example ---
[INFO] com.exampl:example:jar:1.0-SNAPSHOT
[INFO] +-
[INFO] +- junit:junit:jar:4.11:test
[INFO]   \- org.hamcrest:hamcrest-core:jar:1.3:test

So in this example, you got what you had expected. Done. However, there will be times when you’ll find that a version you indicated is not being used, and this should always relate to the dependency appearing multiple times in the tree with different versions and maven selecting another version than the one you want.

Coming to an Agreement

So how can you get maven to go with the version you want? You need get the dependency tree to agree with you and the two tactics here are both pretty straight forward.

If you own it, Upgrade it

If the dependency is another artifact you manage, first upgrade it there. Lather, rinse, repeat.

Exclude it

You can also tell maven not to recursively descend into parts of the tree using exclusions.
For example suppose you wanted a newer hamcrest-core then 1.3:


This will tell maven not to bring the artifact in from there. With this in place your dependency should win the argument. Mind you, there are times where you just can’t win. If the artifact has significantly changed and the developer hasn’t maintain backwards compatibility you may not be able to find a version that works for both (XML parsers used to be notorious for this).

Keeping Watch

This process is not automatic, it involves some work, and always taking the latest and greatest, while it may avoid tech debt has real risks of its own, so when do you do it? That is a matter of preference, but here is something to at least help you keep an eye on change. Add the following to your pom.xml‘s plugins:


With that in place every time you do a mvn install you’ll get a report of the updates available to you and you can decide when you want to act on it.

Maybe you don’t need a newer version at all

If this plugin was reliable, I’d have noted it as a first step, but as it is I’ll mention it only as a footnote. Running:

mvn dependency:analyze

Will analyze your dependencies and inform you of those that you don’t even need in the pom at all. This happens in the normal course of life, you add a dependency and then refactor the code and the orphan the dependency. The problem is this plugin yields a lot of false positives. I’ll run it, and then try commenting out each dependency I think are in fact now not needed, and then install to see if it was true.

And if You Want it Automagic

Maven also allows ranges in the version numbers. This will allow you to say things like any version greater than X. This can be useful, but it does mean that each time you build the exact same project you might get a different suite of dependencies. So it you’re looking for control and reproducibility this isn’t the way to go.