From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

why are you unable to change the project name?

this is something that should wire up via whatever is used in `maven-publish`'s `publishing` block -- but there is no immediate reason I see that you could not try changing the project name if that way isn't working

This flag might be on or off, in fact I could change the name in settings but then I also have to conditionally change the dependency, sometimes project(“:B”) and sometimes project(“:B-suffix”) depending on the flag. Maybe it’s possible but it doesn’t feel right to me, I’m not sure.

Now B’s artifact is changed in maven-publish configuration as you said, but it’s not automatically picked up by A. Should it be? Or how do I? Thanks!

can you share `B`'s `build.gradle`(`.kts`)?

or rather, the place where you are configuring the artifact ID

It’s a bit complex :sweat_smile: I use <https://github.com/deepmedia/MavenDeployer|this plugin>, applied by some other plugin... it exposes an `artifactId` property which gets later passed to the maven publication. Does A’s `maven-publish` look into B’s maven publications for this wiring? And how does it match the right publication? I probably have more than one

The exact logic is in <https://github.com/gradle/gradle/blob/401c31af0193c7deaf5e6e5853d2a20ac632df5e/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/ivyservice/projectmodule/DefaultProjectDependencyPublicationResolver.java#L59|https://github.com/gradle/gradle/blob/401c31af0193c7deaf5e6e5853d2a20ac632df5e/sub[…]/projectmodule/DefaultProjectDependencyPublicationResolver.java> ; looking at the plugin it seems like it should get set in time to wire up here without issues, but it's too complex for me to be sure. I would debug the configuration via <https://docs.gradle.org/current/userguide/troubleshooting.html#sec:troubleshooting_build_logic> , add a breakpoint in this method (for when `project.getName().equals("B")`), and see what it thinks the artifact id is and how it got there.

That's very helpful, thank you! I will investigate deeper and see what's happening.

We also use dokka and kotlin serialization in the child project.  It also errors with `org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'org.jetbrains.dokka'] was not found in any of the following sources` if we don't have `id 'org.jetbrains.dokka' version "1.7.10" apply false` in the parent project's `build.gradle`.  Is there a way to avoid that as well?

Builds aren't meant to be composed as subprojects: settings.gradle.kts is ignored, gradle/libs.versions.toml too (as the conventional path for version catalog).
In your case you could probably have the Parent settings.gradle.kts configure the version catalog to load the Child/gradle/libs.versions.toml file; but I'd rather look at composite builds (`includeBuild`) as that's the proper way to compose builds together in Gradle.

You need a 3rd build that produces a module that contains the shared code. Then you should be able to include it in both `build-logic` and your main build.

How do I address the module of the 3rd build? `implementation(project("some-module"))` doesn't work

Using coordinates, in the shared build you need to set `group` and then consume using something like `implementation("com.acme:shared")`

ah nice, didn't know it would work, thanks!

Does this guide on handling mutually exclusive dependencies answer your question here? <https://docs.gradle.org/current/userguide/dependency_capability_conflict.html>

Thanks for the link. I read through it, and I don’t think it quite addresses this situation. There can be many dependencies in the `tomcatShared` configuration, and also they are not really “conflicting” with mutually exclusive dependencies in the other configurations.

I think what I need is a way to get the declared dependencies of a configuration, plus their transitive dependencies.

Another way to think of the problem:
• `cloud` extends `tomcatShared`
• `tomcatShared` extends `runtimeOnly`
• Need resolved versions aligned across all of them (thus the extensions)
• Finally, need to exclude all `tomcatShared` deps + transitive deps from the `cloudWar` (since those get provided as shared Tomcat libs at runtime, not bundled into the war file)
Is there a way to get only the declared dependencies plus their transitives, for a configuration? Not including the base `runtimeOnly` dependencies?
Another way to think of the problem is: configuration

Can you subtract the runtimeOnly from the collection?

That might work. The examples I found looked hacky and I didn’t find a syntax that worked in my testing. Do you have any examples I might check out?

I also just found <https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/Configuration.html#shouldResolveConsistentlyWith-org.gradle.api.artifacts.Configuration-|Configuration#shouldResolveConsistentlyWith>, that looks interesting.

Try to set the constraint in the `buildscript { dependencies { ... } }` block for the `classpath` configuration

If your goal is only to replace the artifacts (while keeping the transitive dependencies), then you should probably rather use a component metadata rule (for all variants, replace the files with the one you want ; or if you want it only for one configuration, then add a variant and apply the appropriate attributes to the configuration so that this new variant is selected).

AFAICT, using file dependencies is seen as _deprecated_ and discouraged. You'd better have a repository from which to resolve the artifacts (that you can also "assign" to a single configuration if needed), or possibly use a composite build.

This is very unfortunate. In our case, we have complex dependencies. They usually involve a JNI layer with many native dependencies and no publishing to speak of. So, we have to actually have 2 projects?
1. to test based off the latest integration remotely published and with a native zip, locally extracted
2. to test based off the full installer package that contains all of the artifacts
I don't see why this has to be the case. There seems to be too much thought given to metadata about the artifacts. If I substitute a module with a local file, it should just end there and accept that this is a required dependency for this/these configuration(s). Otherwise, it would be up to me to provide more checks for the substitution rule.

Shouldn't be a problem unless you introduce a real loop

Nice! Let's try it :slightly_smiling_face:

Following up on this, is there a way to express this cycle in a "centralized way", i.e. without having to remember to do it in both projects as they always require the cycle?
Any solution I'm finding so far goes pretty much against the advice in <https://docs.gradle.org/current/userguide/cross_project_publications.html> and I'm assuming project isolation might make this even more complicated?

You could encode it in a (convention) plugin that the projects apply that somehow “knows” which project has which “position” in the cycle. I think it depends on the use case. Hard to give a more concrete answer without knowing that :slightly_smiling_face:

It's a <https://github.com/apollographql/apollo-kotlin|GraphQL plugin>. There's a tradeoff to find between:
1. generating all the possible types 
2. keeping the compilation time reasonnable (some schemas are really big and generating everything takes a *lot* of time)
We have a solution that only generates the used types that works well as long as there is a single module. Now if multiple modules are involved, it's not possible to know what types are used without scanning all modules first. The process of scanning is relatively fast so I was thinking of a 2 pass process:
• scan all downstream modules for used types
• do the actual codegen for these types. The generated code is then used downstream

&gt; You could encode it in a (convention) plugin that the projects apply that somehow “knows” which project has which “position” in the cycle
There would have to be some knowledge about the name of the "other" module. It can be really anything. The typical scenario is:
• one `schema` module
• one `queries` module
The `queries` module depends on code generated in `schema` :
```// queries/build.gradle
dependencies {
  implementation(project(":schema"))
}```
The `schema` module depends on used types from queries:
```// schema/build.gradle
dependencies {
  usedTypes(project(":queries"))
}```
But the names can really be anything

anyone happen to have written a script to convert a Maven BOM into a toml catalog file by any chance :smile:

since say, spring boot doesn’t yet a catalog for their Spring Boot Dependencies, thought it would be nice to convert their <https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.7.5/pom|bom> into a catalog to get the typesafe accessors.

wanted to check if anyone else had already created / knew of such a script before reinventing the wheel

Read the comments of that issue, there are some work-arounds as far as I remember. Other than that probably nothing changed afaik.

Thanks. Workaround is not solution for large team (100+ devs)

Maybe you could consider using the `includegit` Gradle plugin instead: <https://melix.github.io/includegit-gradle-plugin/latest/index.html>

read <https://github.com/gradle/gradle/issues/15383>

Ahh yes, with Kotlin DSL the error message is actually understandable (to me), thanks for the pointer!

Not until you open a feature request and it maybe gets added :slightly_smiling_face:

Other than that, you can create a convention plugin that applies the plugins you want to have as bundle and then apply that convention plugin instead.

If it would not work at all, it would complain about `org.testcontainers:kafka`, not `org.testcontainers:junit-jupiter`.
And if I try your setup, all dependencies resolve properly but `org.testcontainers:junit-jupiter` is not included at all, so I guess you miss some details here.

oh right, sorry, I posted wrong error message.
It actually complains it can't download exactly `org.testcontainers:kafka`
```Could not find org.testcontainers:kafka:.
Required by:
    project :```
Have updated original error message I posted

Well, but then it is like I said, works perfectly fine here.
Can you provide an MCVE?

gradle-issue1.zip

Sure, here is complete `build.gradle`:
```plugins {
    id "java"
}

group "org.example"
version "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    implementation platform("org.testcontainers:testcontainers-bom:1.17.4")
}

java {
    toolchain.languageVersion = JavaLanguageVersion.of(18)
}

testing {
    suites {
        integrationTest(JvmTestSuite) {
            dependencies {
                implementation project
                implementation "org.testcontainers:kafka"
            }
        }
    }
}```
And packaged "hello-world" project which allows to reproduce it

Interesting. That error doesn't appear anymore, after I press "reload gradle project" in IntelliJ...

Hi, I have a complex situation of circular dependencies and I need help on how to fix it in some way. I'm creating Kotlin typings for a multi npm package TypeScript library, with one gradle module per npm package.
There is the `core` package which is requiring the `utils` package, but the `utils` package uses some types from the `core` package, because in TypeScript you have a `import type` statement that lets you import types from another package, without having to declare this package as a dependency.
But for my case, what should I do ? As my Kotlin typings must be equal to the TS typings, and it would be weird to duplicate the imported types (with `import type`) as a solution :thinking_face:
So, what should I do ?

both your rules have a typo:
`this.capability.group == "org.codehaus.groovy" || this.capability.group == "org.codehaus.groovy"` second test should be `org.apache.groovy`

thanks I was trying multiple options, but it did not work even with correct checks

The version alignment just cares for the single modules having the same version.
You need to add the capability like you mentioned, then it should initially fail without the `resolutionStrategy` due to same capability. Then the `resolutionStrategy` should resolve that conflict and you only need to check for the `org.apache.group` capability that should then be on both variants in your `resolutionStrategy`.

unfortunately that does not seem to work it fails with:
```&gt; Could not resolve all files for configuration ':lib:testCompileClasspath'.
   &gt; Could not find org.codehaus.groovy:groovy:.
     Required by:
         project :lib &gt; org.gebish:geb-core:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-ast:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0 &gt; org.gebish:geb-implicit-assertions:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0 &gt; org.gebish:geb-exceptions:6.0
   &gt; Could not find org.codehaus.groovy:groovy-templates:.
     Required by:
         project :lib &gt; org.gebish:geb-core:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-ast:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0 &gt; org.gebish:geb-implicit-assertions:6.0
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-waiting:6.0 &gt; org.gebish:geb-exceptions:6.0
   &gt; Could not find org.codehaus.groovy:groovy-macro:.
     Required by:
         project :lib &gt; org.gebish:geb-core:6.0 &gt; org.gebish:geb-ast:6.0```
my configuration:
```configurations.configureEach {
    resolutionStrategy {
        capabilitiesResolution.all {
            if (this.capability.group == "org.apache.groovy") {
                this.selectHighestVersion()
            }
        }
    }
}
dependencies {
    components.all(GroovyVersionAlign::class.java)
    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
    testImplementation("org.gebish:geb-core:6.0")
}
class GroovyVersionAlign : ComponentMetadataRule {
    override fun execute(context: ComponentMetadataContext) = context.details.run {
        if (id.group.equals("org.codehaus.groovy")) {
            allVariants {
                withCapabilities {
                    addCapability("org.apache.groovy", id.name, id.version)
                }
            }
        }
    }
}```
Also maybe I oversimplified the question, I need align version of all groovy libraries to same version so if in some project I have only plain groovy library and in some transitive dependency there is groovy-xml I need also groovy-xml to be on the same version. On the simple project I was simply able to make it work by depending on groovy-all without any custom ComponentMetadataRules since new groovy libraries have also capability with codehaus group and thus conflicting during resolution. But if I have only groovy in that module then it failed since there is groovy 4.0.6 and groovy-macro 3.0.12 on the compile classpath

Ah, ok, as they set the capabilities properly for Groovy 4, then you of course do not need the `addCapability`, just the `resolutionStrategy`. And as they also define the version alignment properly in Groovy 4, you also not need the manual version alignment. If you do the version alignment you should use the non-virtual `groovy-bom` though.

So if you know Groovy 4 will be present, this is enough (just tested):
```configurations.all {
    resolutionStrategy {
        capabilitiesResolution.all {
            if (capability.group == "org.codehaus.groovy") {
                selectHighestVersion()
            }
        }
    }
}
dependencies {
    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
    testImplementation("org.gebish:geb-core:6.0")
}```
If you know for sure you only have Groovy 3, this would be enough:
```dependencies {
    components.all&lt;GroovyVersionAlign&gt;()
    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
    testImplementation("org.gebish:geb-core:6.0")
}
class GroovyVersionAlign : ComponentMetadataRule {
    override fun execute(context: ComponentMetadataContext) = context.details.run {
        if (id.group.equals("org.codehaus.groovy")) {
            belongsTo("org.codehaus.groovy:groovy-bom:${id.version}", false)
        }
    }
}```
And if you might have Groovy 3 and 4 or maybe not, then this works:
```configurations.all {
    resolutionStrategy {
        capabilitiesResolution.all {
            if (capability.group == "org.codehaus.groovy") {
                selectHighestVersion()
            }
        }
    }
}
dependencies {
    components.all&lt;GroovyVersionAlign&gt;()
    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
    testImplementation("org.gebish:geb-core:6.0")
}
class GroovyVersionAlign : ComponentMetadataRule {
    override fun execute(context: ComponentMetadataContext) = context.details.run {
        if (id.group.equals("org.codehaus.groovy")) {
            belongsTo("org.codehaus.groovy:groovy-bom:${id.version}", false)
        }
    }
}```

thank you for suggestions, unfortunately it still behaves incorrectly for me
I applied the last suggestion with both 3 and 4, the compilation now works (somehow?!?) but it has still multiple versions of groovy on the classpath as can be seen by configuring compile task:
```tasks.named&lt;GroovyCompile&gt;("compileTestGroovy") {
    doFirst {
        println(classpath.files.filter {it.name.contains("groovy")}.joinToString("\n") { it.parentFile.parentFile.parentFile.parentFile.name + ":" + it.name })
    }
}```
then if I have groovy-all:4 then the classpath is like:
```org.apache.groovy:groovy-ant-4.0.6.jar
org.apache.groovy:groovy-cli-picocli-4.0.6.jar
org.apache.groovy:groovy-console-4.0.6.jar
org.apache.groovy:groovy-datetime-4.0.6.jar
org.apache.groovy:groovy-docgenerator-4.0.6.jar
org.apache.groovy:groovy-groovydoc-4.0.6.jar
org.apache.groovy:groovy-groovysh-4.0.6.jar
org.apache.groovy:groovy-jmx-4.0.6.jar
org.apache.groovy:groovy-json-4.0.6.jar
org.apache.groovy:groovy-jsr223-4.0.6.jar
org.apache.groovy:groovy-macro-4.0.6.jar
org.apache.groovy:groovy-nio-4.0.6.jar
org.apache.groovy:groovy-servlet-4.0.6.jar
org.apache.groovy:groovy-sql-4.0.6.jar
org.apache.groovy:groovy-swing-4.0.6.jar
org.apache.groovy:groovy-templates-4.0.6.jar
org.apache.groovy:groovy-test-junit5-4.0.6.jar
org.apache.groovy:groovy-test-4.0.6.jar
org.apache.groovy:groovy-xml-4.0.6.jar
org.apache.groovy:groovy-yaml-4.0.6.jar
org.apache.groovy:groovy-4.0.6.jar
org.codehaus.groovy:groovy-3.0.12.jar```
if I have only groovy:4 then:
```org.apache.groovy:groovy-4.0.6.jar
org.codehaus.groovy:groovy-macro-3.0.12.jar
org.codehaus.groovy:groovy-templates-3.0.12.jar
org.codehaus.groovy:groovy-3.0.12.jar```
and just for fun if I have both groovy-all:4 and groovy:4 (compilation fails like with the original message) and classpath is like:
```org.apache.groovy:groovy-ant-4.0.6.jar
org.apache.groovy:groovy-cli-picocli-4.0.6.jar
org.apache.groovy:groovy-console-4.0.6.jar
org.apache.groovy:groovy-datetime-4.0.6.jar
org.apache.groovy:groovy-docgenerator-4.0.6.jar
org.apache.groovy:groovy-groovydoc-4.0.6.jar
org.apache.groovy:groovy-groovysh-4.0.6.jar
org.apache.groovy:groovy-jmx-4.0.6.jar
org.apache.groovy:groovy-json-4.0.6.jar
org.apache.groovy:groovy-jsr223-4.0.6.jar
org.apache.groovy:groovy-macro-4.0.6.jar
org.apache.groovy:groovy-nio-4.0.6.jar
org.apache.groovy:groovy-servlet-4.0.6.jar
org.apache.groovy:groovy-sql-4.0.6.jar
org.apache.groovy:groovy-swing-4.0.6.jar
org.apache.groovy:groovy-templates-4.0.6.jar
org.apache.groovy:groovy-test-junit5-4.0.6.jar
org.apache.groovy:groovy-test-4.0.6.jar
org.apache.groovy:groovy-xml-4.0.6.jar
org.apache.groovy:groovy-yaml-4.0.6.jar
org.apache.groovy:groovy-4.0.6.jar
org.codehaus.groovy:groovy-macro-3.0.12.jar
org.codehaus.groovy:groovy-templates-3.0.12.jar
org.codehaus.groovy:groovy-3.0.12.jar```
I really don't have idea how this could happen since the capabilities seems to be set correctly but it behaves like there is conflict only for some libraries or even no conflict in the last case...

Hm, I have a feeling this is a bug you should report to Gradle.
With
```    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.codehaus.groovy:groovy:3.0.12")```
it works perfectly as expected, but with
```    testImplementation("org.apache.groovy:groovy-all:4.0.6")
    testImplementation("org.gebish:geb-core:6.0")```
it does not work properly.
Unless there is some detail I don't see why it works differently there.

The `capabilitiesResolution` is only called for `org.codehaus.groovy:groovy-macro` and `org.codehaus.groovy:groovy-templates`, but not for `org.codehaus.groovy:groovy`.

Ok I will create bug. Thank you for your help with this.

Here is the link to the issue: <https://github.com/gradle/gradle/issues/22609>

Very good idea to use the linen link as reference :ok_hand:

There is no issue, as that is expected.
If you build a convention plugin that applies another plugin, the project building that plugin needs to depend on that plugin for the production code of the plugin. You actually can use the plugin id though like `&lt;plugin id&gt;:&lt;plugin id&gt;.gradle.plugin:&lt;plugin version&gt;`. If you use the plugin exclusively in the convention plugin, just add it as a normal lib entry in the version catalog. Or you can extract the plugin id and version from the accessor and build up the syntax I mentioned.

And of course there is <https://github.com/gradle/gradle/issues/17963|https://github.com/gradle/gradle/issues/17963> to thumbs up and follow.

Yeah I suspected that was intended and with issue I also meant feature request in case it is intended, so thanks for the link!

Interesting point about the strict format of the plugin artifacts, thanks for that info :)

Those are what the docs call "marker artifact" and which are the way how a plugin id in the plugins block is mapped to an actual dependency

You can define the plugin in the version catalog as a ‘plugin’ and reference that in the dependencies block using extension functions to build up the syntax:


```public fun DependencyHandlerScope.plugin(id: String, version: String): String =
    "$id:$id.gradle.plugin:$version"

public fun DependencyHandlerScope.plugin(plugin: Provider&lt;PluginDependency&gt;): Provider&lt;String&gt; =
    plugin.map { "${it.pluginId}:${it.pluginId}.gradle.plugin:${it.version}" }```
settings.gradle.kts
```plugin("nullaway", "net.ltgt.nullaway").version("1.3.0")```
build.gradle.kts
```implementation(plugin(libs.plugins.nullaway))```

Simplified plugin aliasing syntax available in version catalog: `plugin("nullaway" to "net.ltgt.nullaway:1.3.0")`

using:
```public fun VersionCatalogBuilder.plugin(alias: Pair&lt;String, String&gt;) {
    val (id, version) = alias.second.split(":")
    plugin(alias.first, id).version(version)
}```


you could <https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:excluding-transitive-deps|exclude> the transitive dependency.

I'm told that this solution isn't working; Gradle evidently still wants to see the POM file before it processes exclusions

Doesn’t seem right.  It won’t attempt to formulas something that I’d excluded.  Perhaps it isn’t fully excluded - a build scan can help determine where the dep is pulled in from 

Or maybe the use of detached configurations should be discouraged in general? Right now it feels like a "not quite thought through" / "finished" concept to me.

I think it is the other way around.
Detached configurations are fine, but when the capabilities were introduced this gap you observe was not properly considered.
I think you are right and there is no way, at least I'm not aware of any.
A detached configuration is for ad-hoc usage of a plugin to resolve some dependency without polluting the configurations of the project.
I guess this should be reported as bug / shortcoming.

&gt;  Detached configurations are fine, but when the capabilities were introduced this gap you observe was not properly considered.
Yes I agree.

&gt;  I guess this should be reported as bug / shortcoming.
I'll open an issue (as I did not find an existing one).

I tried to fix the concrete case by changing the input of the task in question. But the Android Gradle Plugin hard codes things so much that it is not possible to remove/change what it does when setting up the LinkTask.

This is too opinionated in my mind. The nice thing about Gradle is usually that even if there are shortcoming like this, you can still do some customisation by reconfiguring tasks directly. It's unfortunate, that the Android Plugin seems to remove this flexibility on purpose (e.g. by calling `disallowChanges()` on task input file collections).

Funny enough, this highlights how good it would be if more libraries/tools would detect such issues in their own builds already before they publish their dependencies.

Problem is caused because `com.android.tools:repository` directly depends on the `javax` while it's transitive dependency depends on the same under the `jakarta` name. I doubt that this mismatch is on purpose.

Yeah, probably not :slightly_smiling_face:

Of course in this case the root is (again) the *so unnecessary* move to suddenly put the `javax` package into the `jakarta` component. Which is causing so much pain across the whole ecosystem.
I understand that sometimes are bad decisions and mistakes are made. But this was just so necessary....

FTR: Best solution I could come up with was to fix the metadata of `com.android.tools:repository` so that the conflict would not arise in the first place:

```    withModule("com.android.tools:repository") {
        allVariants {
            withDependencies {
                removeIf { it.name == "javax.activation" }
                add("jakarta.activation:jakarta.activation-api")
            }
        }
    }```

Ah, right, good solution finally.
Well, at least a solution. :smile:

Are you sure the rename was unnecessary?
Could well be that they were not allowed to use "java" in the name because of some registered trademarks or similar.

Yes the general rename was necessary for legal reasons (although I don't like that as well).

But what they did is doing it in two steps. Causing inconsistency between `package names` , `module coordinates`  and jpms `module names` . For example for _javax.activation_

`javax.activation:activation:1.1.1`  -&gt; contains `javax` package
`jakarta.activation:jakarta.activation-api:1.2.1`  -&gt; *still (!)* contains `javax` package
`jakarta.activation:jakarta.activation-api:2.0.0`  -&gt; contains `jakarta` package

There should have never been a `1.x` version under the new coordinates (with the old package)

And this all on top that there are already conflicts, because often there is an API `jar` and an implementation `jar` , where the implementation also includes the API classes.

And then there are copies of some of the APIs under different names by _glassfish_ and _tomcat_ etc.

So even without the name change the situation was already (too) complex.

Yeah, big ball of mud that always makes problems, I agree

basically this issue exactly, and I don't agree with the answer <https://github.com/gradle/gradle/issues/12108>

If our artifactory is just a mirror of mavenCentral and Gradle Plugin Portal, they should be fine to use as a fallback for reproducibility

If you have repositories A, then B, then C.
You have a good version of x in A and there is an evil version of x in C.
Now A is broken due to DDoS attack and your build will continue to run, taking the evil version of x from C.

Or you have same repositories, A has version 10 of x, C has version 3 of x and you declare dependency on latest.integration version of x. You build while A is online and build with version 10. Now A has some problems and suddenly your build builds with version 3.

I completely disagree with the answer too. A build systems job is to build, “features” like that should be configurable

We use fixed versions everywhere, my life would be so much better if we could disable that. 

I’m even fine with it being the default, as there are a lot of cases that people would care. But it should be disableable

It should imho at most be enableable, as it is a big security risk, especially without verification enabled.
With verification enabled it could maybe be the default.
But well, you have to convince the Gradle guys about that. :slightly_smiling_face:

&gt; A build systems job is to build, “features” like that should be configurable
And a good build systems job is to build reliably, securly,  and reproducably,
which you would not have with the requested change.
That's why I said it should at least be off by default but maybe enableable with some switch.

I might remember wrongly, so better just try it out, but iirc then attributes defined on concrete dependencies are considered, attributes declared on the configuration are not.

You remember correctly. Attributes are not "inherited".

Iirc by default `--configuration` defaults to `compileClasspath` in Java projects. Try with `--configuration runtimeClasspath`

ah, yes, thank you, that does give a bit more information

```org.apache.commons:commons-lang3:3.12.0
  Variant runtime:
    | Attribute Name                 | Provided     | Requested    |
    |--------------------------------|--------------|--------------|
    | org.gradle.status              | release      |              |
    | org.gradle.category            | library      | library      |
    | org.gradle.libraryelements     | jar          | jar          |
    | org.gradle.usage               | java-runtime | java-runtime |
    | org.gradle.dependency.bundling |              | external     |
    | org.gradle.jvm.environment     |              | standard-jvm |
    | org.gradle.jvm.version         |              | 17           |
   Selection reasons:
      - By constraint: version resolved in configuration ':test-module:compileClasspath' by consistent resolution

org.apache.commons:commons-lang3:3.12.0
\--- runtimeClasspath

org.apache.commons:commons-lang3:{strictly 3.12.0} -&gt; 3.12.0
\--- runtimeClasspath```
though i’m not sure what “by consistent resolution” means

<https://docs.gradle.org/current/userguide/resolution_strategy_tuning.html#sec:java_consistency>

Sure, just set the correct attributes, or use the `testFixtures(...)` helper that does it for you.

but that helper bring fixtures into fixtures/test right? I would like to get some module fixtures as implementation configuration in another module

It brings it in where you declare it. `implementation(testFixtures(project("a:b:c"))`. It basically just sets the proper attributes on the dependency which you could also do manually if you prefer.

For the convention of functionalTest/integrationTest, the correct way to add the fixtures to those source sets is the next snippet, right?

```dependencies {
    "integrationTestImplementation"(testFixtures(project))
}```

There are multiple ways.
Actually imho that string-y version is one of the more uglier ones.
How do you create those test types?
Using the test suites plugin?
Then I would declare it there like the other dependencies also.

Do you mean if I config the test task the fixtures are automatically added?

I asked how you define the `integrationTest`

If you use the jvm test suites plugin,
then I'd just declare it there like the other dependencies:
```testing {
    suites {
        val integrationTest by registering(JvmTestSuite::class) {
            dependencies {
                ...
                implementation(testFixtures(project()))
            }
        }
    }
}```

Ah, it is under a convention plugin, that is the reason I shared it so.

I am not using test suites yet.

I am doing something like:

```sourceSets.named("functionalTest") { set -&gt; set.dependencies { configureTestDependencies() } }

private fun KotlinDependencyHandler.configureTestDependencies() {
    implementation(testFixtures(project))
    ...
}```
I have to investigate about test suites yet and how they work on all kind of Kotlin projects (probably they don't work on KMP right? If so, I don't want to mix yet different concepts)

And no idea how to properly do test fixtures with KMP

Indeed even text fixtures doesn’t work with kmp but I need them now to share in those source sets the fakes 

Maybe you have to do `project.dependencies.testFixtures(...)`

yeah I am doing that as KotlinDependencyHandler doesn’t have it

```public fun KotlinDependencyHandler.testFixtures(notation: Any): Dependency =
    project.dependencies.testFixtures(notation)```

Test fixtures are just a feature variant that you can select setting the right attributes.
I'd expect that to work fine with KMP.

not sure about kmp, but android + kotlin doesn't work

The `testFixtures(...)` helper is just setting the attributes for you

<https://youtrack.jetbrains.com/issue/KT-50667/Support-compiling-android-testFixtures-sources-in-the-kotlin-android-gradle-plugin>

So either set the attributes manually, or use the `testFixtures(...)` method from `project.dependencies`

I will try with KMP, but if there is an android target it will not work.

Yep, I will use that to avoid doing that manually, really thank you :slightly_smiling_face:

Well, if even Android also comes into play, I'm more out of the picture, also not doing much Android here.

I just know that AGP always does things separately and often is not compatible with standard stuff

I don’t know the details, Android with Java works with fixtures, but after mixing with kgp…

there are some things I don't like from AGP/KGP related to not using the standard things, for example I have created today an issue and I commented

```// KMP project
println("Sources: ${the&lt;SourceSetContainer&gt;().size}") // Sources: 0
println("Sources: ${the&lt;KotlinMultiplatformExtension&gt;().sourceSets.size}") // Sources: 83

// Kotlin JVM project
println("Sources: ${the&lt;SourceSetContainer&gt;().size}") // Sources: 2
println("Sources: ${the&lt;KotlinJvmProjectExtension&gt;().sourceSets.size}") // Sources: 2```
```val topLevel: SourceSetContainer = sourceSets
val javaContainer: SourceSetContainer = java.sourceSets
val kotlinContainer: NamedDomainObjectContainer&lt;KotlinSourceSet&gt; = kotlin.sourceSets```

Lack of consistence of different behaviors and types

```However we cannot choose between the following variants of project :hubdle-gradle-plugin:
          - runtimeElements
          - testPluginClasspath```
Looks like I have to fix my custom configuration used for Gradle testkit tests

I have found <https://discuss.gradle.org/t/manually-selecting-library-variant-by-forcing-attribute-doesnt-work/43825/2|this reply> from you <@URQ797WRW> about not indicating `GRADLE_PLUGIN_API_VERSION_ATTRIBUTE` as it is calculated automatically,
which I had to add to my custom `testPluginClasspath` configuration some months ago.

Now I am on Gradle 7.6 and on Kotlin 1.7.20. Should it be safe to delete that attribute?

```configurations.creating {
    val kotlinVersion = Version.safe(project.getKotlinPluginVersion()).getOrNull()
    if (kotlinVersion != null &amp;&amp; kotlinVersion &gt;= Version("1.7.0"))
        attributes { attributes -&gt;
            attributes.attribute(USAGE_ATTRIBUTE, objects.named(JAVA_RUNTIME))
            attributes.attribute(CATEGORY_ATTRIBUTE, objects.named(LIBRARY))
            attributes.attribute(
                GRADLE_PLUGIN_API_VERSION_ATTRIBUTE,
                objects.named("7.0")
            )
        }
}```

Yep it is working :slightly_smiling_face:

one option for distributing constraints/rules on dependencies (direct &amp; transitive) is to use custom <https://github.com/nebula-plugins/gradle-resolution-rules-plugin|Nebula resolution rules> for alignment, replacement, substitution, exclusion.  Useful for say forcing secure versions.  Behind the scenes this is using the various Gradle APIs to create replacement rules, alignment rules, constraints, etc - which can, of course, be accomplished in other ways (e.g. your own custom plugin distribution that calls the same APIs).

<https://docs.gradle.org/current/userguide/platforms.html#sub:platforms-vs-catalog|Version catalogs> were not intended/designed to, by themselves, affect dependency resolution.

&gt; A catalog helps with centralizing the dependency versions and is only, as it name implies, a catalog of dependencies you can pick from. We recommend using it to declare the coordinates of your dependencies, in all cases. It will be used by Gradle to generate type-safe accessors, present short-hand notations for external dependencies and it allows sharing those coordinates between different projects easily. Using a catalog will not have any kind of consequence on downstream consumers: it’s transparent to them.

just saying that with 1) you can import a catalog and override the versions declared in it at the same time. The Micronaut catalogs declare versions for each library, so that you can do that.

so the first argument: "so cannot use the native version overriding feature in Version Catalog anymore" is technically wrong:
```versionCatalogs {
     create("foo") {
        from("...")
        version('groovy', '3.0.5') // override the version in the catalog
     }
}```

"no native support for publishing a catalog and a platform from the same source" is not quite true either: the `java-platform` plugin allows that. What is not very well supported is having _properties_ for versions in the generated POM file.

Eventually, as Chris said, catalogs are _not_ designed to "override" dependency resolution. That's why you need both a catalog (to "list" dependencies) and a platform/BOM (to carry constraints)

Thanks very much for the responses. I will look into the Nebula resolution rules.

Melix, regarding the `"so cannot use the native version overriding feature in Version Catalog anymore"` -  the Solution (1)  also calls for applying the micronaut platform/bom.  So using the catalog version overriding. e.g. `version('groovy', '3.0.5')` , may or may not work because the version is also hardcoded in the platform. It will work in some situations and won't in some . While that's predictable, it's not something I'd want non-expert Gradle users to deal with if there's a way.
If there's no platform involved, the overriding will be a breeze for direct dependencies.  Let me know if I'm missing something.

Melix, Regarding `catalogs are _not_ designed to "override" dependency resolution`   , I agree with that too. The proposed solution (3) will not change the design mechanics of the catalogs. We will only be adding extra convenience methods on the Gradle side to promote better utilization of catalogs for different scenarios. For example,

```constraints{ api myCatalog.bundles.someBundle } // I think this already works today. So technically an auto-generated bundle which includes all library entries will pretty much work like a platform without needing one. That is a big deal, to me, because there won't be a split brain anymore on versions between the catalog and the platform. 

constraints{ api myCatalog.bundles.someBundle {strictly true}} // adding such convenience might go a long way .. ```
Just my 2c based on playing with catalogs in the past few months to roll them out across the board at my place.

while large parts of (3) are doable today with Gradle API, that isn’t the intended use of catalogs.  it mixes declaring a _dependency_ version with declaring a _constraint_ (maintenance headache for your catalogs - what is this definition used for?) - and for limited value, given the range of dependency management adjustment that is typically required.  For example, that would offer no way of performing alignment, replacement, substitution or exclusion of dependencies, nor is there an avenue to handle capability/variant resolution.

Same as when declaring dependency directly in build script without version. It only works if somewhere else a dependency on the same lib with version is present in the dependency tree, or at least some version constraint like from a BOM or platform.

I don't understand why I'd need to declare repos in pluginManagement, since I'm using the dependency as a regular project dependency, not as an applied plugin

Maybe it's required to build your included build?

Wait, AGP is a regular dependency of `settings-plugin-included-build` , right?

But it's a plugin dependency of your main build I guess?

Yep

Main build
• includes build of settings plugin
    ◦ settings plugin has a regular dependency on AGP
• applies settings plugin

the transitive dependencies of your settings plugin are seen as "plugin" dependencies from your main build

Not sure if that helps but I've gone a similar route of factoring in the repositories declaration in a composite build lately. I used <https://github.com/apollographql/apollo-kotlin/blob/main/gradle/repositories.gradle.kts|a script that's applied in different builds> and I'm happy with it

Neat trick! But I'm not sure how to make it work with a build that contributes a Settings plugin. With 1, I get the same "Could not resolve AGP" error, but I can't use 2 because it's a Settings plugin ("Plugin with id 'plugin' not found.")

This seems to work:
```pluginManagement {
  includeBuild("settings-plugin-included-build")
  apply(from = "./gradle/repositories2.gradle.kts")
}```
repositories2.gradle.kts:
```listOf(pluginManagement.repositories, dependencyResolutionManagement.repositories).forEach {
  it.apply {
    mavenCentral()
    google()
    gradlePluginPortal {
      content {
        includeModule("org.gradle.kotlin.embedded-kotlin", "org.gradle.kotlin.embedded-kotlin.gradle.plugin")
        includeGroup("org.gradle.kotlin")
        includeModule("me.champeau.gradle", "japicmp-gradle-plugin")
        includeModule("com.gradle.publish", "plugin-publish-plugin")
        includeModule("com.github.ben-manes", "gradle-versions-plugin")
      }
    }
    @Suppress("DEPRECATION")
    jcenter {
      content {
        // <https://github.com/Kotlin/kotlinx-nodejs/issues/16>
        includeModule("org.jetbrains.kotlinx", "kotlinx-nodejs")
      }
    }
  }
}```

Just apply from inside the `pluginManagement{}` block

Note: it only works in Kotlin DSL for some reason. In Groovy, it complains that "pluginManagement only allowed in Settings scripts"

There's nothing lightweight you can embed. Your best shot might be to use the Tooling API to instrument Gradle

Do you mean running the actual Gradle as a separate process and get information from it via the tooling API?

If so then maybe I'll have to stick to this maven resolver. I'm a bit frustrated with it given the amount of boilerplate setup, and inexistent doc, hence why I was hoping for Gradle to save me on this :smile: But I guess it would overcomplicate things to spawn an extra process for it

You can use the tooling API in "embedded" mode that will not fork another process. But this might "complicate" your current running process :wink:

But yes, there's nothing "lightweight" available

Thank you very much for the details. I had never looked into the Tooling API. Am I right that it is rather meant to drive an existing Gradle build (with build scripts and all)?

My use case can be reduced to the really simple case of having one set of artifact coordinates (groupId, artifactId, version), and downloading all dependencies and get a handle on the downloaded jar files. It seems that using the Tooling API would mean generating a build script and then running Gradle on it, which seems a bit overkill, right?

But you might think it is more complex than it is.
You do not need to "run gradle in a separate process and then connect to it using the tooling api".
You would generate your small build script, and then you tell the tooling api to run that build. The tooling api will then care about starting a Gradle daemon that runs the build for you, so it should be quite easy.

You could then do the lazy way and write your generated build script so that it prints the paths and you parse the output, or you can do it the better way, asking the tooling api to give you the dependeny files. It is exactly what IDE integrations do.

as an alternative, it doesn't support GMM and other features, but <https://get-coursier.io/> does provide a simple API to resolve Maven artifacts

<@URQ797WRW> even if it doesn't make the code I write myself complicated, it does feel like a lot will be going on for just downloading a few jars, and the memory and processing overhead compared to the current alternative may be significant. I do value the benefit of having Gradle dependency conflict resolution, but I'm not sure this would be worth it. I'll keep the option in mind, though.

We might eventually move from Kotlin Scripting to an actual generated Kotlin+Gradle project in the far future, in which case this approach with Gradle Tooling API would be perfect.

I guess the overhead will not be *that* significant, but you would need to measure to know :slightly_smiling_face:

For the sake of the exercise, if you repeatedly need to download artifacts, you could keep the daemon alive. If it is only needed for that it could be started with a tiny heap.

And you would have the benefit of the Gradle Module Metadata being used / ability to use feature variants and so on, all the nice things you can use when using a Gradle build. :-)

And it could also reuse the cached files from other Gradle builds that also needed those files and so on

The use case at hand is a Kotlin Script DSL that we process rather unconventionally. So we embed the Kotlin compiler, and need to download dependencies by hand. This happens on the fly in a short-lived docker container (itself possibly spawned in a short-lived VM), so we wouldn't benefit from a longer-lived daemon, nor Gradle caches.

Currently the annoying part is that dependencies added to the script via `@file:DependsOn` are processed independently, via a Maven resolver. The only thing I'm trying to resolve by hand here is our own DSL runtime (apart from the user dependencies), which has transitive dependencies, but is currently passed as a fat jar :face_vomiting: with all the problems that come with it. Eventually I'll need a way to resolve dependency conflicts between the user's dependencies and our own runtime+transitive dependencies, but that's not for today I guess

Kotlin scripting itself uses Aether, which I assume is where you started investigating <https://github.com/JetBrains/kotlin/blob/master/libraries/scripting/dependencies-maven/src/kotlin/script/experimental/dependencies/maven/MavenDependenciesResolver.kt|https://github.com/JetBrains/kotlin/blob/master/libraries/scripting/dependencies-m[…]pt/experimental/dependencies/maven/MavenDependenciesResolver.kt>

Exactly. Actually initially the `.main.kts` implementation (which is not the same as our own `.space.kts` in Space Automation) used an Ivy-based resolver, and we still use this implementation at the moment in Automation.

I'm switching right now to this `MavenDependenciesResolver` in our own implementation to get rid of Ivy, but this only concerns user dependencies provided by `@file:DependsOn`. Our built-in DSL dependency is provided separately and still resolved manually using Ivy. This is the thing I'm also replacing now, using Aether too, but independently of this `MavenDependenciesResolver`.

I don't think there should be harm, it is just unclean and unnice, but shouldn't be related to the problem you describe imho.

looks like it won't work unless the Provider&lt;ExternalModuleDependencyBundle&gt; is an instance of
```DefaultValueSourceProviderFactory.ValueSourceProvider
(ref: org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyConstraintHandler#doAddProvider)```
which is an internal class and I couldn't find a way to instantiate it.

Looks like the plugin author brought this up back in 2014: <https://discuss.gradle.org/t/is-the-default-configuration-leaking-into-independent-configurations/2088/6>

I didn't even bother trying something like this, it would surely just crash and burn in a modern Gradle project with configuration caching and everything, right?

Hm, the `project.group` switcheroo actually does work, but my Gradle experience teaches me that using hacks is an extremely bad idea

Maybe a clean solution could be to have an included build that uses two configurations to get each of the jars and in one you use <https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/ResolutionStrategy.html#getUseGlobalDependencySubstitutionRules--> to get the binary dependency from the repository.

One concern I have about using a composite build is that composite builds don't compose. I should point out that I'm not doing this for a specific project, but for many projects throughout my company, so I need something that will behave well as a custom plugin

What do you mean that composite builds don't compose?

Meaning you can't include composite builds in another composite build

That is years outdated knowledge.
That was a restriction in the beginning of composite builds that is long gone.
Works perfectly fine.

That's an important piece of information! I thought that I read about that limitation somewhere in the documentation within the last year, but I can't find it even in the Gradle 6.0 documentation

Is there a recommended way to create an included build programmatically, without writing out build files to the filesystem?

You suggested:
&gt; Maybe a clean solution could be too have an included build that uses two configurations to get each of the jars
How would I do this from a plugin?

The `getUseGlobalDependencySubstitutionRules` appears to target this use case

<https://github.com/gradle/gradle/commit/144afc3ce96f4a60831ca35db75f064c50856ef3|Bingo>, just gotta figure out how to use it

<@U023HSZL88M> Is this feature expected to work within the current module, so that a project can obtain its own previously published jar file? The integration tests don't appear to test that case

According to documentation it does not, that's why I said you need to use a composite build together with it

Yes. Sadly it does not work with the *current* module. Because the *current* module (the *root*) has such a special handling in dependency resolution. You would have to do the comparison from another module. (`getUseGlobalDependencySubstitutionRules` may still be helpful then, but is only needed if you also use included builds.)

Can you do it somehow without a composite build <@U023HSZL88M>?

&gt; Because the *current* module (the *root*) has such a special handling in dependency resolution
This is what I was wondering: does the root module even _have_ a dependency substitution rule, or is it special-cased somewhere?

It is special-cased (by the way some code in the resolution engine has evolved starting with Gradle 0.1, where some of the code was copied from Ivy :smile: )

&gt;  Can you do it somehow without a composite build
In a single build you don't necessarily have substitutions for the subprojects. But I keep forgetting the details. I think if you don't add any substitution rules, projects and published versions can both be selected and the normal version conflict resolution (higher version wins) is used.

In my experiments, a dependency on `my-group:my-project` will _always_ resolve to the current module, irrespective of version (and irrespective of `resolutionStrategy`)

There is
```resolutionStrategy.preferProjectModules()```
to always select the local project

But if you don't turn that on, I think you can make it select a published version instead. But there is no strategy to "always select the published version".

Maybe it works with a *strict* version that points at the published version you want to select (?)

Nah, tried that. The `!!` syntax, right? It still resolves to the current module

Looks like this feature request is still open: <https://github.com/gradle/gradle/issues/1629>

The hilarious thing is that you can set `project.group` to some other value, perform the dependency resolution (eagerly), and then restore the old value; that works fine!

But I am sure that you somehow can get the published version selected.... at least it was possible at some point in the past (that's why `preferProjectModules` was introduced)

Looks like you can `force` a dependency edge

Then maybe the cleanest (?) setup would then be to use an extra build and include the one for which you want to do the comparison. Then you can use `getUseGlobalDependencySubstitutionRules` to make a clear decisions.
But maybe that's overkill for your setup...

I work in my company's developer tooling division. I'm not trying to solve this problem for a single build, but for basically all builds. I need a packaged solution I can vend, probably some sort of plugin

And I don't think an extra build can be created programmatically; it would require additional files, checked in to git

So if I can't do this through Gradle, I'll whip out an HTTP client and do it myself. I'd prefer to not have to do that

&gt;  The hilarious thing is that you can set `project.group` ....
Maybe this "hack" isn't too bad then. If it works. Change the group, fetch the previous version, set the group back.

Imo it's  a missing feature in Gradle and that would justify using such a workaround for me.

I've learned that Gradle plugin development goes much more smoothly when you do everything strictly by the book and don't get creative with hacks...

But first I'm going to look into this:
```        dependencies.create(
            group = "com.plexxi",
            name = "PlexxiCore",
            version = "${project.property(DbProps.REFERENCE_VERSION_PROP)}",
            ext = "war").apply {
            isForce = true
        }```

Setting `isForce = true` is a fresh idea I haven't tried yet

I found the original "design doc" and one of the original posts from the forum which let to the introduction of `preferProjectModules` back in the day. I don't know if this helps, but maybe:
• <https://github.com/gradle/gradle/blob/82d482df8192dba085dd6f8b06bad4f41e805753/design-docs/dependency-management-projectpriority.md>
• <https://discuss.gradle.org/t/project-dependencies-participate-in-conflict-resolution/18875>

FYI this Javadoc in `ExternalDependency` is garbled:
```@deprecated Use {@link MutableVersionConstraint#strictly(String) instead.}```
It renders as:

`isForce` has no effect, it's just another form of version syntax. I'm currently looking at using `ArtifactResolutionQuery`

Looks like that API can only be used to obtain sources and stuff

OK, I've stepped through the code and concluded that this behavior is hardcoded into the graph resolution logic. <@U023HSZL88M>, this is why setting strict versions, forcing versions, etc doesn't do anything. See in particular <https://github.com/gradle/gradle/commit/d2ba516ee2a79d5fc33241a24fd33db4dcee141a|this commit>, which specifically prevents "selection" from being deferred on the root module; it is performed as soon as the graph is constructed. Here, "selection" refers to the eviction of all other versions of the root module (see `ModuleResolveState#select`). This all happens early during the process of _graph_ resolution, before _artifact_ resolution can run, and it's a fixed behavior that is unaffected by any public APIs I'm aware of.

<@UAB9WQKJ4> Why <https://github.com/gradle/gradle/commit/d2ba516ee2a79d5fc33241a24fd33db4dcee141a|this commit>? It's tagged with `groovy-4-compile-problem`, but that's all I know

For anyone coming across this thread in the future: I caved and used the `project.group` hack. I figured the code in question was unlikely to change in a way that would suddenly break this approach, given its age, complexity, and overall design