How to detect compileClasspath configuration in project.configurations

Help/Discuss
1

We are using some logic similar to this (for checking specific dependency resolution conflicts): failOnVersionConflict only for certain dependencies - #3 by ljacomet

We are only interested in dependencies with implementation configuration, so basically in the compileClasspath and runtimeClasspath.

Is there a way to filter the configuration in the ConfigurationContainer to these types when using project.configuration?

2

To me it is unclear what you are asking.
The post you linked to tells you exactly what to do, doesn’t it?

3

Hi @Vampire, thanks for your answer.
We use this check in our build-logic and for me it’s unclear how we can filter for compileClasspath and runtimeClasspath configurations (for a project that has mixed Kotlin only and Android modules). Currently we simply filter the configurations by name. I was wondering if there is a better way:

configurations.configureEach {
    if (name.contains("Compile") && !name.contains("TestCompile")) {
        incoming.afterResolve {
            resolutionResult.allComponents {
                if (!selectionReason.isConflictResolution) return@allComponents
                val resolvedVersion = moduleVersion?.version ?: return@allComponents

                if (isNonStable(resolvedVersion)) {
                    throw GradleException(
                        "Unstable transitive dependency in ${this@failOnNonStableVersionConflict.name} found: $moduleVersion " +
                        "Please check the dependency graph and either remove/revert the dependency, which drags this in or set this version explicitly."
                    )
                }
            }
        }
    }
}
4

“better way” simply depends on what you actually want to match.
If you want to match all configurations that have Compile in the name but not TestCompile in the name, then you test exactly that.
But you did not really say what your conditions are that you want to match for.
Once you are able to formulate that properly, you most probably also have the according if-condition if the current is not the one already. :slight_smile:

5

Hi @Vampire thanks again. I can see that my question is not super clear.

The previous example, which our code is based on, uses Groovy to call testCompileClasspath.get(). Probably I am somewhat confused by that.

The equivalent Kotlin code would be named("testCompileClasspath").get(), right?

Because this would mean the previous example was also “just” based on String comparison and there is no attribute in the configuration to distinguish compileClasspath configurations from other configurations?

6

attribute in the configuration to distinguish compileClasspath configurations

Well, again, it depends on what you try to match.
If you want to match configurations that request via attributes variants that are to be used during compilation, you could check that.
The question is just whether you really want to do that.
Besides that those manual attribute comparisons are quite hairy iirc as they are not really designed for that.

1 Like