Different Dependency Version Declarations in Gradle

1. Overview

Gradle is one of the most popular build tools for JVM projects. It provides various ways to declare and control our dependency versions.

In this short tutorial, we’ll see how to define the latest dependency versions in Gradle.

First, we’ll investigate different ways we might want to define a dependency’s version. Then, we’ll create a small Gradle project in which we’ll specify a few third-party libraries. Finally, we’ll analyze Gradle’s dependency tree and see how Gradle handles different version declarations.

2. Declaring Versions

2.1. Exact Version

This is the most straightforward way to declare the dependency version. All we have to do is specify the exact version we want to use in our app, such as 1.0.

Most official dependencies usually use only numeric versions such as 3.2.1. However, a dependency version is a string, so it can contain also characters. For example, there is a 5.2.22.RELEASE version of Spring.

2.2. Maven-Style Version Range

If we don’t want to specify an exact dependency version, we can use a Maven-style version range, such as [1.0, 2.0), (1.0, 2.0].

The square brackets [ and ] indicate an inclusive bound. On the contrary, the round brackets ( and ) indicate an exclusive bound. What’s more, we can mix different brackets in a version declaration.

2.3. Prefix/Wildcard Version Range

We can use a + wildcard to specify a dependency version range — for example, 1.+. Gradle will look for dependencies whose version matches exactly the portion before the + wildcard.

2.4. Using the latest Version Keywords

Gradle provides two special version keywords we can use for any dependency:

• latest.integration will match the highest versioned SNAPSHOT module
• latest.release will match the highest versioned non-SNAPSHOT module

3. Version Range Pros and Cons

Using a Maven-style or wildcard version range as a dependency version can be useful. However, we have to consider both the advantages and disadvantages of that approach.

The biggest advantage of a version range is that we always have the latest dependency available. We don’t have to search for new dependency releases each time we’re building our app.

However, always having the latest dependency available may be also a big disadvantage. Our application may behave differently from one build to the next just because there was a new release of some third-party dependency we’re using in our app that changed behavior between releases without our realizing it.

Depending on our requirements, specifying a version range for a dependency can be helpful. Nevertheless, we must be careful and sure about which versioning algorithm a dependency is following before we use it.

4. Creating a Test Application

Let’s create a simple Gradle application to try a few dependencies with different version declarations.

Our app will consist of only one file, build.gradle:

plugins {
    id 'java'
}

group = "com.baeldung.gradle"
version = "1.0.0-SNAPSHOT"
sourceCompatibility = JavaVersion.VERSION_17

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
}

Next, we’ll add a few org.apache.commons dependencies with different version declarations.

Let’s start with the easiest one, the exact version:

implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.12.0'

Now, let’s use a Maven-style version range:

implementation group: 'org.apache.commons', name: 'commons-math3', version: '[3.4, 3.5)'

Here we specified, that we want a commons-math3 dependency whose version will be between 3.4 inclusively to 3.5 exclusively.

The next dependency will use the wildcard version range:

implementation group: 'org.apache.commons', name: 'commons-collections4', version: '4.+'

We want to have the latest commons-collections4 dependency whose version matches the 4. prefix.

Lastly, let’s use the Gradle latest.release keyword:

implementation group: 'org.apache.commons', name: 'commons-text', version: 'latest.release'

Here’s our full dependencies section from the build.gradle file:

dependencies {
    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.12.0'
    implementation group: 'org.apache.commons', name: 'commons-math3', version: '[3.4, 3.5)'
    implementation group: 'org.apache.commons', name: 'commons-collections4', version: '4.+'
    implementation group: 'org.apache.commons', name: 'commons-text', version: 'latest.release'
}

Now, let’s see how Gradle resolves our version declarations.

5. Showing a Dependency Tree

Let’s use the Gradle dependencies task to see a dependency report:

$ gradle dependencies

compileClasspath - Compile classpath for source set 'main'.
+--- org.apache.commons:commons-lang3:3.12.0
+--- org.apache.commons:commons-collections4:4.+ -> 4.5.0-M2
+--- org.apache.commons:commons-math3:[3.4, 3.5) -> 3.4.1
\--- org.apache.commons:commons-text:latest.release -> 1.10.0

At the time of writing, the latest commons-math3 dependency version that matches the specified range was 3.4.1. We can see that Gradle used that version.

Moreover, 4.5.0-M2 was the latest commons-collections4 version that matched the 4.+ wildcard.

Similarly, 1.10.0 was the latest release version of the commons-text dependency.

6. Conclusion

In this article, we learned how to declare dependency versions in Gradle in various ways.

First, we saw how to specify the exact dependency version as well as version ranges in a Gradle build script. Then, we tried a few ways of expressing our dependencies.

Finally, we checked how Gradle resolved these versions.