Resolve dependency constraints.

[anuraaga]

Dependency constraints can be used to set versions, and in particular can be used with the java-platform plugin to define all constraints in a single location. It would be convenient if these constraints were resolved by the plugin since then instead of resolving the dependencies of all projects in a monorepo controlled by a platform, just need to resolve a single project for better performance and simpler output.

I am wondering whether this feature should be restricted to projects with the java-platform plugin. Let me know if you have thoughts.

Reference

• https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:dependency_constraints
• https://docs.gradle.org/current/userguide/java_platform_plugin.html

Fixes #350

[jmfayard]

Looks promising to me.

Can you add an example of use in the samples?
You can then try it with:

# Publish the latest version of the plugin to mavenLocal()
$ ./gradlew install  

# Try out the samples
$ ./gradlew -p examples/groovy dependencyUpdate
$ ./gradlew -p examples/kotlin dependencyUpdate

[anuraaga]

Thanks - added examples

[ben-manes]

In other cases we've guarded using metaClass.respondsTo("..."). Which do you consider preferable?

[ben-manes]

Its probably not simpler to combine this with the other createQueryDependency, though the duplication could lead to mistakes of fixing one instead of both.

[ben-manes]

Thanks for the PR and test case. I think it makes sense to go in. What do you think @jmfayard?

Would constraints someday be used to implement BOMs or are they totally separate? My only concern is if someone has a large BOM but only uses a few dependencies, and the constraint resolution causes them to see the universe. That seems unlikely but worth asking.

[jmfayard]

I have no further remarks. I learned a lot of new things by reading the two links from the PR

[anuraaga]

Switched to using respondsTo.

It's an interesting question of if in the future, Gradle would internally implement a BOM dependency by translating it into constraints. I feel as if this wouldn't happen, since a Configuration basically reflects the settings of the project and such opaque translation would probably not happen at that layer, BOM's work fine just using the normal dependency resolver already. I am more worried about if some other plugin, like nebula, does such translation as it could be a way to support BOM for old versions of Gradle that didn't natively resolve them - it's probably a bit too much though to worry about interactions with other plugins unless getting a report IMO.

[ben-manes]

That makes sense. Thanks again. 😄

[ben-manes]

Releasing v26.