Dependency version constraints for all configurations

Help/Discuss
1

Hi to all,

I want to migrate from spring-dependency-management plugin to gradle6 both platform and constraints feature. For the second feature I have thought to migrate everything in dependencyManagement/dependencies block to dependencies/constraints, but have the following problem:
In spring dependencies plugin you define versions for all configurations ( you do not have to add any type of configuration) , but for constraints in gradle 6 I have only found examples, which define a version explicitely for one configuration. How is the default migration path for this scenario? I’d like to configure versions for all configurations, even for the ones, which maybe are applied in any subproject later on (e.g. earlib)

Thanks for any help,
Cheers
Markus

2

Any ideas?:slight_smile:

3

In general, I would check if you really need to declare the constraints for all configurations. There is now a distinction between configurations for declaring dependencies / dependency constraints and configurations for other things (resolving/consuming dependencies). So for example, if you only have java-library projects, constraints declared on api would end up being used everywhere.

But I see that there can be use cases where you have different project types with different configurations involved. In that case you could do something like this:

dependencies {
    constraints {
        configurations.all { conf ->
            if (!conf.canBeConsumed && !conf.canBeResolved) {
                add(conf.name, 'org:my-dep:1.0')
                // more constraints
            }
        }
    }
}
4

Hi Jendrik,
thank you for your answer,
what other solution can I use to cover the following use case:

  • constraints in root project
  • adding a new configuration in a submodule, which only contains let’s say swagger and does not extend compile

At this point I don’t have this configuration in place in configuration phase of root plugin.
Do I have to extend compile in every new used configuration to solve this?

Cheers
Markus

5

Hi @moley ,

I am not sure I understand the use cases.

If it is a timing issue with cross-project configuration (configuring all subprojects from root) you should probably use plugins.withType. E.g.:

subprojects {
    plugins.withType(JavaLibraryPlugin) {
        // at this point, everything is setup for Java and 'api', 'implementation' etc. are available
    }
}

For adding a new configuration: it really dependends on for what you use it in the end. Can you elaborate more for what you need the additional configuration?

Note: “compile” is deprecated. If you add new configurations in Java devlopment (which you normally do not need to do), you should make one or more of the following configurations extend the new configuration: compileClassspath, runtimeClasspath, apiElements, runtimeElements. See also: https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph

6

Hi @jendrik

thank you for your answer. We have different scenarios were we are adding configurations in submodules:

  • ear plugin: is applied in one submodule and adds earlib and deploy configurations
  • using generators (jaxb, antlr, swagger): sometimes we add a configuration which include the generator classes itself to not distribute the dependencies

And configuring the version constraints is done in rootproject in allprojects{} closure.

So OK - if it is a viable solution to extend from another configuration I will do this, I guess.

Thank you

7

I see. In that case you are right and I was probably wrong. For a generator it makes sense to use a separate configuration. And if you wan to have the “normal” dependencies included there it makes sense to extend “compile” (although instead of extending compile you might want to extend one or more of the new configurations in the future).

8

Ok, thanks for your help, so I will solve it this way.
Cheers and
have a nice christmas time

Markus