Java-platform plugin - avoiding constraints already declared by an in use third party?

Hi, we’re currently migrating our multi-project builds from gradle 4 to 6 and as part of that we’ve started using platforms and declaring our own using the java-platform plugin. So far it’s working well.

However, I was wondering if it’s possible to have our build fail or produce a warning if one of our internally declared platforms and a third party one have declared the same dependency constraint.

A specific example would be:

  • Our build is using spring-boot as a platform dependency
  • It is also using a platform created internally as part of the project
  • I’d like a way to prevent the team from adding dependency constraints into the internal platform that are already defined by Spring, regardless of the version number.
  • The more I can automate this check the better.
  • e.g. I want to avoid people adding jackson dependencies to the internal platform since the spring BOM provides these already.

Hi @ivanmcshane,

There is no built-in tool for this in Gradle, but you can write your own analysis task. There is a resolution result API which is largely undocumented right now unfortunately. But you can follow the Javadoc.

You could write an analysis task that iterates through the resolution result and collects duplicated constraints and their origin. Then, if at least one origin is from you local platform and another one is from somewhere else, you can fail. Here are some entry points for the API:

tasks.register("platformAnalysis") {
    doLast {
        configurations.runtimeClasspath.get().incoming.resolutionResult.allDependencies.forEach { dep ->
            if (dep.isConstraint ) {
                dep.from // where was this declared
                val to = dep.requested as ModuleComponentSelector // what component does it point to?
                to.group  // group
                to.module // name
        }
    }
}

Many thanks @jendrik, I’ve created a custom task based on your advice and it’s working as desired.

More testing is required on our side but it has already spotted a few cases of duplicate declarations in the builds I’ve tested.

1 Like