How to define dependency versions in the parent project for all the sub-projects?

Help/Discuss
1

say i have parent P and children A,B,C.

In the parent project P, i want to set the versions for the dependencies of A, B, C . Not necessarily all the dependencies are used in all the child projects. Say A and B have 2 dependencies d1 and d2 in common, B and C have 3 d3 d4 d5 in common.

I want to list down the versions of d1, d2, d3, d4, d5 in parent build.gradle and in the child projects, i want to just list down the dependencies with the version from parent build.gradle.

i dont want to use version constants.

2

I’d define this logic as a configuration rule which will make the version mappings available to all subprojects.

subprojects {
    ext.depVersions = ['dep1': '1.5', dep2: '2.0']
}

In any of the subprojects you can then use this version when declaring a dependency.

dependencies {
    compile "org.company:dep1:${depVersions.dep1}"
}

There are some other, more sophisticated approaches you can take. Some of them are described in the slides for the talk “Advanced Dependency Management with Gradle”.

i dont want to use version constants.

I don’t quite understand your request here.

3

I am looking for something similar to dependencymanagement in maven parent projects where we define versions of all the dependencies and in sub-projects we will give the group and artifact information and not the version information.

4

This use case is described in the slides that I provided. You can find a recording of the talk on YouTube. The result could look like this:

dependencies {
    compile defaultVersion('org.springframework', 'spring-core')
}

This is not functionality that is built into Gradle out-of-the-box so you’d have to write some code. In a nutshell you’d expose an extra method on DependencyHandler that looks up the specific version for the provided groupId and artifactId. Alternatively, you might want to also have a look at the Nebula Dependency Recommender plugin. It provides fairly flexible approach to the problem.

5

Whilst I also prefer @bmuschko’s approach of version variables, there’s also the dependency-management-plugin which is configured in a similar style to maven’s dependencyManagement