Gradle Dependency Management: Using Versions from Properties

build.gradle file with version properties

• ext { ... }: This block defines extra properties that can be used throughout the build.gradle file. In this case, we define properties for the versions of JUnit, Apache Commons Lang, and Guava.
• junitVersion = '5.8.1': Assigns the version number '5.8.1' to the junitVersion property.
• implementation "org.apache.commons:commons-lang3:${commonsLangVersion}": Declares a dependency on Apache Commons Lang, using the commonsLangVersion property to specify the version. The ${} syntax is used to interpolate the property value into the string.
• The other dependency declarations follow the same pattern, using the respective version properties.

plugins {
    id 'java'
}

group 'com.example'
version '1.0-SNAPSHOT'

ext {
    junitVersion = '5.8.1'
    commonsLangVersion = '3.12.0'
    guavaVersion = '31.1-jre'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation "org.apache.commons:commons-lang3:${commonsLangVersion}"
    testImplementation "org.junit.jupiter:junit-jupiter-api:${junitVersion}"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:${junitVersion}"
    api "com.google.guava:guava:${guavaVersion}"
}

test {
    useJUnitPlatform()
}

Benefits of Using Version Properties

Using version properties offers several advantages:

• Centralized version management: All dependency versions are defined in one place, making it easy to update them.
• Consistency: Ensures that the same version of a library is used across all dependencies.
• Readability: Makes the build.gradle file more readable by using named properties instead of hardcoded versions.

Real-Life Use Case

In a large project with many modules and dependencies, managing versions can become complex. Using version properties ensures that all modules use the same version of a library, preventing version conflicts and ensuring consistent behavior.

Best Practices

• Use descriptive property names: Choose property names that clearly indicate the dependency they represent.
• Define properties in the ext block: This ensures that the properties are accessible throughout the build.gradle file.

Alternatives

An alternative to the ext block is to define versions in the gradle.properties file. This allows for externalising these versions and avoids cluttering the build.gradle

Pros

The pros of this solution are:

• Easy version management in one place
• Readability
• Consistency of dependency versions

Cons

The cons of this solution are:

• Requires extra setup
• Increases verbosity slightly