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

Gradle Community

The question is, where does it come from?
In a simple project applying `java-library` for example I only have
• apiElements
• mainSourceElements (i)
• runtimeElements
• testResultsElementsForTest (i)

and if you run `outgoingVariants --variant default`?

`default` has no attributes set by the Java plugins normally.
It should be considered a legacy configuration and no plugins should add attributes to it.
I suspect that the Kotlin plugin ends up adding attributes to it as I remember it doing that for all consumable configurations.

I am getting following variant selection issue:
```Could not determine the dependencies of task ':kotlin-gradle-plugin-idea:test'.
&gt; Could not resolve all task dependencies for configuration ':kotlin-gradle-plugin-idea:testRuntimeClasspath'.
   &gt; Could not resolve project :kotlin-gradle-plugin.
     Required by:
         project :kotlin-gradle-plugin-idea
      &gt; The consumer was configured to find a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm'. However we cannot choose between the following variants of project :kotlin-gradle-plugin:
          - default
          - gradle70RuntimeElements
          - runtimeElements
        All of them match the consumer attributes:
          - Variant 'default' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a component, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attributes:
                  - Doesn't say anything about its component category (required a library)
                  - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its usage (required a runtime)
          - Variant 'gradle70RuntimeElements' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attribute:
                  - Provides attribute 'org.gradle.plugin.api-version' with value '7.0' but the consumer didn't ask for it
          - Variant 'runtimeElements' capability org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.255-SNAPSHOT declares a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm'```
Seems `default` and `runtimeElements` has same capability and then Gradle fails to select one

or there is way to say Gradle to select variant with most matching attributes?

Ah, ok if I use `--all`, I also see `default` and `archives` legacy ones, just never  had a problem with them.

I think it automatically selects the one with the most matching attributes, except if there are ones that are too similar like both have the same 4 attributes and both have 1 unmatched but different, then they are equal or something like that.
What does `outgoingVariants --all` say for you?

&gt; I think it automatically selects the one with the most matching attributes
`runtimeElements` has the most matching attributes, though `default` has 5 without any value

Can you show what that command says, or is it confidential?

&gt; What does `outgoingVariants --all` say for you?
<https://ge.jetbrains.com/s/u2y5ykm5ynhkk/console-log>

&gt; I suspect that the Kotlin plugin ends up adding attributes to it as I remember it doing that for all consumable configurations.
You are right - there are 2 attributes seems added by KGP. I will open an issue for this. Is there a way to detect such legacy configurations?

Hm, seems I still don't fully understand the variant selection process.
If you have a variant of a plugin For gradle 7+ and one for older, it selects the proper ones, though they have the same attributes, just one has additionally the Gradle version attribute.
So no idea, why it does not simply select the right one. Maybe <@UAB9WQKJ4> can tell.
But as he already said, it is probably the Kotlin plugin adding attributes to legacy configurations.
For me `default` has no attributes at all, in your case it has `org.gradle.jvm.environment` and `org.jetbrains.kotlin.platform.type`.
So I guess the Kotlin plugin should be fixed and as a work-around on the producer side, you remove the attributes the plugin added.
Or as a consumer-side work-around you can use a component metadata rule to remove the attributes.

&gt; Is there a way to detect such legacy configurations
My first guess would be, if they are resolvable and consumable

&gt; (l) Legacy or deprecated configuration. Those are variants created for backwards compatibility which are both resolvable and consumable.


&gt; Or as a consumer-side work-around you can use a component metadata rule to remove the attributes.
Do you have such example nearby? I am looking into `ComponentMetadataRule` and seems it only possible either modify existing or add new one attribute

FYI to follow: <https://youtrack.jetbrains.com/issue/KT-51913>

&gt; My first guess would be, if they are resolvable and consumable
Yes, I was right:
```if (configuration.isCanBeConsumed() &amp;&amp; configuration.isCanBeResolved()) {
    type = ReportConfiguration.Type.LEGACY;
}```


I cannot immediately explain why there is confusion in resolution here. It must be something with disambiguation failing to find an intersection. See <https://gradle-community.slack.com/archives/CAHSN3LDN/p1649317045662649?thread_ts=1649275223.542899&amp;cid=CAHSN3LDN> for details on how it works.

&gt; Do you have such example nearby? I am looking into `ComponentMetadataRule` and seems it only possible either modify existing or add new one attribute
tbh, I never tried, I just assumed it works.
But even if you just can modify existing ones and add new ones, then modify one of the two to an incompatible value and it should hopefully work

This is a project dependency, CMR will not apply to it. Instead you should modify the project directly.

Yeah, if it is a project dependency of course, there you have the producer under control.
Should have been clearer.

&gt; then modify one of the two to an incompatible value and it should hopefully work
I've changed one of attribute values in `default` variant and that solved the issue :white_check_mark:

Thank you for discussion :clap:

Fwiw, I wrote a blog post about this: <https://blog.ltgt.net/javax-jakarta-mess-and-gradle-solution/>

Nice summary. We’ll be dealing with the aftermaths of this for a long time still :disappointed:

Oh, and I totally forgot to talk about the API vs implementation JARs too, where the former are a subset of the latter, so you shouldn't/can't use both at the same time either (e.g. `com.sun.mail:javax.mail` _contains_ `javax.mail:javax.mail-api`, same for the Jakarta flavors, and for all versions; for Java Mail it's even worse actually, as `com.sun.mail:javax.mail` is a _bundle_ of `com.sun.mail:mailapi` , `com.sun.mail:smtp`, `com.sun.mail:pop3`, and `com.sun.mail:imap`: <https://javaee.github.io/javamail/#Download_JavaMail_Release>)

Followup post: <https://blog.ltgt.net/javax-jakarta-mess-even-worse/>

:100: agreed. The build should fail. And I think many folks have this situation.

Thanks for starting the discussion. The more I think about it the more I like the idea add a rule that adds the correct “rejects” to existing transitive dependencies. I will give it some more thought and then comment on <https://github.com/jjohannes/java-ecosystem-capabilities/issues/6>

Fwiw, I think the full list of JakartaEE 8 versions is available here: <https://github.com/eclipse/transformer/blob/main/org.eclipse.transformer.jakarta/src/main/resources/org/eclipse/transformer/jakarta/jakarta-versions.properties|https://github.com/eclipse/transformer/blob/main/org.eclipse.transformer.jakarta/s[…]ces/org/eclipse/transformer/jakarta/jakarta-versions.properties>

That’s very helpful. I have been looking for such a list. Thanks.

You can do that via `buildscript { configurations.classpath.resolutionStrategy }` (so it’s “outside” of the pluginManagement block)

i think the issue is here:
<https://github.com/eugene-krivobokov/auto-applied-build-scan-resolving-sample/blob/develop/build-logic-settings/scan/build.gradle.kts#L6>

that line should instead be this:
`implementation 'com.gradle:gradle-enterprise-gradle-plugin:3.9'`

I'm curious, why should that make a difference?
He is depending on the plugin marker artifact, so the mentioned artifact should come in transitively.

I'm just going straight from the samples: <https://docs.gradle.org/current/samples/sample_convention_plugins.html>
They point to the plugin itself and not the marker.

&gt; implementation 'com.gradle:gradle-enterprise-gradle-plugin:3.9'
Wow, it helped!

Here is another interesting point.
It seems applying script to configure repositories also affects the logic.
If I inline repositories instead of reusing script it also seems working.

Ah, so maybe just another script plugin shenenigan.

Btw. please do not use the `-all` distribution.
Especially as you are using the Kotlin DSL in your build scripts, there is absolutely no use for it. It just wastes time, bandwidth, and disk space of anyone and anything using that build.

There is exactly one situation where the `-all` distribution is helpfule. That is to work-around a shortcoming in the IDE and only if you use Groovy DSL and only while you are editing build scripts.
So even with the Groovy DSL, you waste time, bandwith, and disk space of anyone and anything just executing the build.

Thanks for the advice.
We use `-all` distribution for another reason.
We have to proxy all the dependencies in Artifactory. If I'm not mistaken, with `-bin` distribution IDE downloaded sources while sync. We've switched to `-all` to cache it beforehand. Probably, there is a better way to workaround it.

Indeed if you sync the first time a project with Kotlin DSL with the IDE it will download the sources automatically if not present yet.

Btw. if I clone your MCVE and do the change <@UFDR8S97S> suggested, I still get the same error. o_O

That's actually also what I would have expected, really wondering why it helped for you

Btw. another question, why do you add `mavenCentral` after `gradlePluginPortal`?
The plugin portal redirects to JCenter (or a mirror thereof) for things it does not have itself which in turn forwards to Maven Central for things it does not have.
So adding MC after GPP should not actually do anything, should it?

Agree, sounds reasonable.
Probably, I was thinking about mirroring on Artifactory level, that it will hide it from clients.

&gt; Btw. if I clone your MCVE and do the change <@UFDR8S97S> suggested, I still get the same error. o_O
The same, started to fail. It looks flaky, depending on something.

I think you'd have to use `gradle.beforeProject { buildscript.configurations.classpath { resolutionStrategy { … } }` or something like that.

Nope, Gradle is failing with `Cannot change resolution strategy of dependency configuration 'classpath' after it has been resolved`

:thinking_face:  already resolved in `beforeProject`, I'm almost certain I've changed `buildscript.repositories` that way and correctly seen the new URLs being used to download the dependencies in debug logs. Could it be that the `buildscript` wasn't targeting the ones from the project?

Fwiw, I couldn't reproduce that error. I could even add a dependency to the classpath configuration that way, and see it resolved correctly (put a broken one, and saw it fail)
```gradle.beforeProject { buildscript.dependencies.add("classpath", "foo:bar:baz") }```
failing with
```FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'redacted'.
&gt; Could not resolve all files for configuration ':classpath'.
   &gt; Could not find foo:bar:baz.
     Searched in the following locations:
       - <https://repo.maven.apache.org/maven2/foo/bar/baz/bar-baz.pom>
       - <https://plugins.gradle.org/m2/foo/bar/baz/bar-baz.pom>
     Required by:
         project :```


I've tried to use following and it throws error:
```gradle.beforeProject {
    buildscript.configurations.all {
        resolutionStrategy.eachDependency {
            if (requested.group == "com.google.code.gson" &amp;&amp; requested.name == "gson") {
                useVersion(versionProperties["versions.gson"] as String)
                because("Force using same gson version because of <https://github.com/google/gson/pull/1991>")
            }
        }
    }
}```

not using dependency locking on any current projects, but created and maintained something equivalent previously (before Gradle's native dependency locking). other engineers were not happy but pushback was obviated by "our legal department interprets PCI compliance to require this"

That's why I created dependency guard.  Need to share publicly, but happy to do a private demo.

Some info on it: <https://gradle-community.slack.com/archives/CAH4ZP3GX/p1648502397092339>

<@U02JK32G1JT> interesting. I wonder what would make your situation different from mine? Because I tried changing a dependency and got a build failure when running `:dependencies`:
```* What went wrong:
A problem occurred configuring root project 'register'.
&gt; Could not resolve all files for configuration ':classpath'.
   &gt; Resolved 'com.google.protobuf:protobuf-javalite:3.18.1' which is not part of the dependency lock state```
this was for the build classpath

In mine, you can change any dependencies you want.

But if you run `./gradlew dependencyGuard` then it'll compare to the baseline and fail with the difference.   Then you can rebase with `./gradlew dependencyGuardBaseline`.

You can do a dependsOn() if you want to commonly run the `dependencyGuard` task to find the change early, but otherwise you can have CI fail the build with it.

It just forces "intentional dependency changes".  The big part of it is catching transitive dependencies for a specific config.

I have 3 baseline artifacts.
1. artifacts (3rd party) Enabled by default
2. local project modules (disabled by default)
3. tree format (dependencies --configuration blah).
It can compare all 3.  The first one is the most useful, but all can be in certain situations.

I tried dependency locking when it created many files, it was terrible.
Once it's just one file a team tried (and I think they are using it) but the last thing I know is that it was frustrating all the time because if failed when it shouldn't... Mostly it seems an issue of having too many configurations (Android project + typical static analysis tools).

The only reason they wanted to use it is to detect transitive dependencies changing. With dependency locking they can see the change in the PR.

I'm wondering if what I want is dependency verification. But really, neither appears to be quite intended for my use-case, which is simply to see when a version changes or when a new (usually transitive) dependency appears. They both _can_ do that, but that does not seem to be the intended purpose. Dependency verification is probably worth doing anyway, for security reasons, but...

I think your usecase is the same I was speaking of.
"I want to notice changes in transitive dependencies so my app doesn't unexpectedly in runtime later"

(I think it was some jetpack lib that changed for us a couple of times, compiling fine but exploding in runtime)

The "good" of dependency locking in that case is that the PR author sees the change when he has to update the lib, but also is in the PR changelog so everyone can see it.

The bad is..how many configurations your project has? Are you blocking them all?

And I don't have access to the chat anymore, but I think I'm remembering they had an issue with a dependency that is resolved in task execution so it wasn't written.

If your need is only to detect transitive dependency changes in PRs, then have a look at <https://github.com/JakeWharton/dependency-tree-diff>

It's not good you have the same problem as me, but you do!

This is exactly what dependency guard does.  I have 3 formats I support:
• artifacts
• local modules/projects
• tree (using JW's logic)
Will show you the diff of all the transitives and allow you to re-baseline.  Also, error messaging is :100: , so it's clear to see wh at's up.

Let me see if I can open source it this week...

Nice, I pushed up the code to the private Github repo.  Awaiting legal approval, then would just have to setup stuff like CI/CD for it and can share after all that.  Hopefully be end of week :crossed_fingers:

I was able to flip the switch on it: <https://github.com/dropbox/dependency-guard>

It's still a work in progress before I publish a non-snapshot, but it is working, so any feedback is appreciated.  A `0.1.0-SNAPSHOT` is available.

Thanks <@UES7RHBDZ> for using the Github issue track for the feedback you have given so far!

Maven keys dependencies by groupId+artifactId+type+classifier. For one such key there can only be one version and one scope (and one "optionality"), so Gradle is right, this is not a valid Maven POM dependency declaration.

That makes sense… it’s annoying though since optional dependencies are basically just informational to Maven right? There would be no harm in allowing this.

interesting, the build no longer fails when I use `processIsolation()` instead

that's curious. I just printed out `((URLClassLoader)getClass().getClassLoader()).getURLs()` in a simple plugin that I have. the top-level classloader has is no differences between `classLoaderIsolation` and `processIsolation`, containing what I set in the spec `classpath` and my plugin, and the parents of each are identical (up to re-ordering), containing just Gradle and its dependencies.

this is a more complex project, but I was also surprised at the number of classloaders involved

Hey Jendrik :wave:

It rings a bell indeed. But we thought it was fixed in IJ.
See <https://github.com/gradle/gradle/issues/17039>

Thanks for the pointer Louis. Yes I see the warning out of IJ code. That’s why I created the issue I linked above on the IJ side.
I also see it with 6.9.x already. But it sounds very much related. I’ll link the two issues.

This was it a month ago: <https://gradle-community.slack.com/archives/CAH4ZP3GX/p1648502397092339>

Seems related: <https://github.com/gradle/gradle/issues/1629>

Ouch, it's seems like a hard to fix issue.

You would need to rename the dependency so Gradle doesn't need to resolve the version conflict. I guess that's what one of the last messages in the issue suggest using an includedBuild, that at the end is just a wrapper to rename the artifact.

Currently Gradle _always_ puts the current project as the root of the dependency graph. And that root will substitute itself to all matching coordinates.
So you will have to perform the resolution in a different project - that is somewhere where the root has different coordinates.
Adding a feature where you could say that the root is something else and thus resolve older version of the same project has been asked but is not yet implemented.

<@UAJKMRD2Q> could you give `7.5-20220504153215+0000` a try with the elastic build? I'm going to turn your reproducer into an integ test

yes that later snapshot works! :thumbsup: :clown_face: :thumbsup:  wanted to say that was fast but realized you `fixed` this before I even raised the issue :wink:

I guess it is not possible since the test classpaths always contain both the api and the implementation configurations:

Why do you want to test that Gradle works as expected?
Or what is your intention?

I am having a hard time trying to find a way to test that I only declare what's needed for the api configuration so only the intended classes are exposed to consumers and no more. I thought I'd write a test that only had "api" and not "implementation", but I am not finding a way to do that, and the diagram says that too. To have a test with just the the api classes, it's not possible (have to get implementation too).

Just use <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/> then.
It tells you if you have dependencies in api that you should have in implementation and many other things.

Wow, that plugin really is something. Thank you <@URQ797WRW>! :heart:

After using that plugin, I find that for one project it was somewhat helpful, and for another it did not appear to work at all, so I filled an issue <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/issues/668>

You may want to look at the output of `:namespace:subproject:dependencies` to see why Gradle has selected 1.5.2, or a Build Scan. It's hard to say why it was selected without knowing your entire build setup.

buildscan is behind a VPN.

```./gradlew :card:cronjob-unused-payment-balance-processor:dependencies | grep -B 10 kotlinx-serialization-json
Picked up _JAVA_OPTIONS: -Xverify:none
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
     |    +--- io.gitlab.arturbosch.detekt:detekt-tooling:1.20.0 (*)
     |    +--- io.gitlab.arturbosch.detekt:detekt-report-html:1.20.0
     |    |    +--- io.gitlab.arturbosch.detekt:detekt-utils:1.20.0
     |    |    \--- org.jetbrains.kotlinx:kotlinx-html-jvm:0.7.5 -&gt; 0.7.3
     |    +--- io.gitlab.arturbosch.detekt:detekt-report-txt:1.20.0
     |    |    \--- io.gitlab.arturbosch.detekt:detekt-api:1.20.0 (*)
     |    +--- io.gitlab.arturbosch.detekt:detekt-report-xml:1.20.0
     |    |    \--- io.gitlab.arturbosch.detekt:detekt-api:1.20.0 (*)
     |    +--- io.gitlab.arturbosch.detekt:detekt-report-sarif:1.20.0
     |    |    \--- io.github.detekt.sarif4k:sarif4k:0.0.1
     |    |         +--- org.jetbrains.kotlinx:kotlinx-serialization-json:1.1.0
     |    |         |    \--- org.jetbrains.kotlinx:kotlinx-serialization-json-jvm:1.1.0 -&gt; 1.5.2 FAILED```

would it be helpful to post full output?  i guess i am not sure what i am looking at other than the dependency tree jumping from 1.1.0 to 1.5.2 inexplicably

I also get a 404 on <https://repo.maven.apache.org/maven2/org/jetbrains/kotlinx/kotlinx-serialization-json-jvm/1.5.2/kotlinx-serialization-json-jvm-1.5.2.pom>

the latest I see is 1.3.2 <https://repo.maven.apache.org/maven2/org/jetbrains/kotlinx/kotlinx-serialization-json-jvm/>

yeah it doesn't exist.  but where is that dependency coming from is my quesiton.  because sarif4k which is what requires it, only requires 1.1.0

<https://github.com/detekt/sarif4k/blob/0.0.1/build.gradle.kts#L18>

interesting, I would've expected another listing for the dependency indicating why 1.5.2 was chosen there (either because of another dependency on it, or a constraint), but your `grep` shows that's the only listing for it

we do have gradle enterprise; i have not used that support queue but just noticed your gradle engineer tag

`org.jetbrains.kotlinx:kotlinx-serialization-json-jvm:1.1.0 -&gt; 1.5.2 FAILED` indicates that it originally requested 1.1.0, but something else is constraining it to 1.5.2 :thinking_face:

unsure if there is any magic way to share better context

well, you could share a build scan to gradle, since you're a customer :)

<https://gradle.management.earnin.net/s/gr6wjsrh3wrti> i don't think you will be able to access

yea, I suspect not -- I'm not on the GE team so I'm not sure how you are supposed to share that

i can definitely share any parts you're curious about

replace `/s/` with `/scan-dump/` and then share the binary via the proper support channel (I used to be on the GE team :smile: )

is it possible there are component metadata rules or similar to align versions that are erroneously catching this artifact and adjusting it’s version?

i don't think so, we have a base plugin we use which allows us to set dependency versions; i even set that explicitly to 1.1.0

ok.  a build scan will help to understand why that version was resolved.

<https://support.gradle.com/hc/en-us/requests/3955>  unsure if you can see that one i attached scan to there

i will prefer to delete that build scan once you confirm you have it

I don't have access to that, sorry. I'll forward this and see if I can get someone else to assist.

i see this, which is suspicious

`org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:{strictly 1.5.2} -&gt; 1.5.2 (c)`

it is different, but same version and kotlinx

it's this i guess:

`./src/main/kotlin/dependency-versions.gradle.kts:68:  "org.jetbrains.kotlinx" to "1.5.2",`

where are you seeing this being expanded to a raw string?

Here’s a log with example

```[versions]
kotlin = { strictly = "[1.6.0, 1.6.10, 1.6.20, 1.6.21[", prefer="1.6.21" }

[libraries]
kotlin-std-lib = { group = "org.jetbrains.kotlin", name = "kotlin-stdlib", version.ref = "kotlin" }```

```FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Venmo Platform'.
&gt; Could not resolve all files for configuration ':classpath'.
   &gt; Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin:[1.6.0, 1.6.10, 1.6.20, 1.6.21[.
     Required by:
         project :
      &gt; Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin:[1.6.0, 1.6.10, 1.6.20, 1.6.21[.```

AFAICT, `[1.6.0, 1.6.10, 1.6.20, 1.6.21[` is not a valid notation: a range can only give a lower and upper bound.

OH! Well that’s good to know, let me give that a shot :bow:

See <https://docs.gradle.org/current/userguide/single_versions.html> for the syntax

(also, btw, you'd be excluding 1.6.21 but then prefer it)

if the intention is for 1.6.x: `[1.6.0,1.7[` (optionally with a preference for 1.6.21).

thank y’all so much, I figured I was messing something up :bow:

Could consider shading one if the versions to a different package structure, allowing both to coexist

if you need both C_1.0 and C_2.0 but they can't coexist, you will need tricks such as shading or separate classloaders, not much way around that.

Thank you. Shading looks like it's going to work. I didn't realize there were plugins to automate most of it. That'll help a lot.

Glad to hear it.  Shading is mostly straightforward - if there are service descriptor or other files in the jar that reference classnames there's a few extra steps to consider.

Update:

I'm attempting to shade dependency B, along with its transient dependency C_2.0.
I'm using the johnrengelman plugin (<https://plugins.gradle.org/plugin/com.github.johnrengelman.plugin-shadow>).

I've created a Bshade.jar file this way and attached it to the project. It contains B in a renamed package B.shade.B.
I added "B.shade." to all import statements for B in my project, and "find declaration" on those import statements goes to the decompiled .class files in the jar, so it seems to be seeing it correctly.

I think B is trying to load classes through java reflection, and the shading is causing it to fail.
At least, that's what I'm gathering from the errors below:

"java.lang.reflect.InvocationTargetException: null
java.lang.NoClassDefFoundError: B/shade/B/Class1
java.lang.ClassNotFoundException: B.shade.B.Class1"

Is there a workaround for java classes loaded through reflection when shading java dependencies?

hmmm.  that is referencing the shaded classes, which is correct  (reflection issues would show the unshaded class name) - perhaps an incorrect JAR is installed at runtime (s/b the shade d JAR - if that was missing it could cause this).

I have no idea, never used S3.
But what I can say is that `finalizedBy` is proabably a bad idea.
It is executed always, even if the publish task failed.
If you need to do the custom work, you probably better add a `doLast { ... }` action to the existing task that publishes the file, so that it is done as additional action if it otherwise was successful already.

Oh shit, I had no idea finalizedBy had that behaviour. Does dependsOn do that? If B depends on A, B will get skipped if A fails, yea?

Customising doLast of the publish task sounds like a way better approach. I keep forgetting about that hook. That really helps, thanks <@URQ797WRW>

Yes, actually you could probably also make it `dependsOn` *and* `finalizedBy`. Then it should be automatically triggered, but only if it was successful.

The dependsOn and finalizedBy duality sounds like a bit of a hack to get that behaviour. I think in this case doLast is 100% the way to go. No need to add to the task graph if not really needed.

a few ideas:
1. unclear whether there is a readily available hook for ‘onPublish’ to then perform tagging - perhaps a wander through the Gradle source may help there;
2. Add S3 event handler lambda to catch each artifact as it’s provided and add tags (this may not be feasible as the context for tagging is limited to the key)

back to the original question: there is currently no hooks to modify publishing remote calls. Though this is a request we have seen in the past.

<https://docs.gradle.org/6.8/release-notes.html|Gradle 6.8> added that capability.
```java {
    consistentResolution {
        useCompileClasspathVersions()
    }
}```

Manual <https://docs.gradle.org/6.8/userguide/resolution_strategy_tuning.html#resolution_consistency|reference>

Thank you. This is a huge topic, I missed that in the docs

i routinely find new stuff in the docs myself :wink:

Does this also apply for Android projects? :sweat_smile: 

Actually, the `java` snippet I’m not sure, but if it doesn’t work, the mentioned doc shows how you can do that to other configurations

it appears that the `consistentResolution` configuration is only available on the Java plugin extension (`java`).

but you can do this where needed:
```configurations {
        runtimeClasspath.shouldResolveConsistentlyWith(compileClasspath)
    }```

if you use that escape hatch, be sure to catch ancillary configurations such as tests, etc (the consistentResolution configuration does all that for you, for Java projects)

Also be aware that implementation of the consistent resolution is one-to-one, so you can set each configuration to resolve consistently with exactly one other configuration. If you have complex relationships of the configurations be careful to get what you really want. For example there method that configures each compileClasspath to resolve consistently with relevant runtimeClasspath but each pair is independent. So you get consistent versions between them in the main source set, in the test source set but not between main source set runtime/compile classpath and any resolvable configurations for the test classpaths.

I got some strange behaviour with it and version locking but haven't managed to create good reproduce yet to file an issue( Maybe it's just in dependency locking though.

I think _Consistent Resolution_ is on of the most “under promoted” feature right now. :smile:

One pattern I find more and more useful (if you build a single application) is to identify the “application runtime classpath” - i.e. the Configuration that will be used by the application in the end - and make everything consistently resolve with that. I explain this in more detail here:
<https://www.youtube.com/watch?v=YYWhfy6c2YQ&amp;t=305s>

And here I use it in a larger project setup.
For standard JVM: <https://github.com/jjohannes/gradle-project-setup-howto/blob/kotlin/gradle/plugins/base-plugins/src/main/kotlin/org.example.consistent-resolution.gradle.kts|https://github.com/jjohannes/gradle-project-setup-howto/blob/kotlin/gradle/plugins[…]ns/src/main/kotlin/org.example.consistent-resolution.gradle.kts>
And on top for Android: <https://github.com/jjohannes/gradle-project-setup-howto/blob/android/gradle/plugins/base-plugins/src/main/kotlin/org.example.consistent-resolution-android-application.gradle.kts#L8|https://github.com/jjohannes/gradle-project-setup-howto/blob/android/gradle/plugin[…]rg.example.consistent-resolution-android-application.gradle.kts>

I guess the (bad) reason for not promoting it more is that we still have the idea to provide “global” consistency check, which would fail a build if a dependency was resolved to two different versions across configurations _and projects_.
And the reason this would not be a mode is that you most likely want isolated islands of consistency and that forcing resolution to be consistent has too many gotchas across projects.

Example of islands: checkstyle or spotbugs classpath vs. application classpath

Nevermind, found an answer myself, it needs to use `java-library` plugin

Yes, you would normally need that for `api()` as well, but Kotlin adds their own version of it (which I recall had some issues in the past, not sure how it is now)

I don't recall separate thing for that but two things come in mind: use shadow plugin to aggregate all this jars (even if you don't use is result) and you'll get relevant warning. Another way is to use a copy task working on the contents of all that dependencies (including only class files) with duplicates strategy == fail/warn.

hmm ok, thanks. I am trying to move from shadow jar to thin-jar style packaging, and so  seeing if I can retain the build-time resolution of multiple classes. so using shadow jar just as a way of generating a warn might be a decent first pass at this

just found <https://github.com/tehlers/gradle-duplicate-classes-check> :eyes:

And what do you use for thin jar? I migrated to spring boot plugin for that (even for projects without spring) since they have good loader and uber jar layout.

I am moving to a jib-based build using the beryx runtime and jlink plugins

Aah, I use something similar for project on Quarkus (their fast-jar + jib for container build) but without repackaging jdk

I recently learned that the Android Gradle Plugin does this out of the box when processing the class files.
Would be nice to have a similar solution for ‘plain’ Java development. The plugin looks like it can do that. Thanks for sharing.

&gt; I am moving to a jib-based build using the beryx runtime and jlink plugins
&gt; 
Just a personal opinion from doing the same recently: don't
It is very inflexible and the developers too.
I had to jump several hoops to get it running like expected, including using the filter plugin to exclude all files they include and define my own layout to make it work properly. And the final strike when I switched to a proper Docker build was, when I tried to use the Java 8 image as base because it is smaller than the Java 17 image and I have my own runtime image and Jib didn't allow it as a measure to protect people shooting their own feet, but without an option to suppress or downgrade this check and without them even considering adding it. Now the build runs perfect and the image is approximately half the size with `debian:stable-slim` as base. (I couldn't use it as base image for Jib, as I need font support which doesn't work with it but needs an additional Debian package)

Don't get me wrong, moving away from far jar is great, and always the right choice. Just not with Jib except for very simple cases.

Interesting. So far I have not had any issues. That filter plugin thing, was that because of the default extra directories they set?

<@URQ797WRW>, could you share what do you choose in the end? Plain `Dockerfile`s, custom plugin or something else?

Plain `Dockerfile` combined with Ben Muschkos Docker plugin to build and then save the Docker image to a tar.gz archive.

Oh I didn't know the bmuschko plugin could do tar.gz I thought it only built against a docker daemon

&gt; Interesting. So far I have not had any issues. That filter plugin thing, was that because of the default extra directories they set?
&gt; 
Actually more because of the whole concept. I don't want `java` as entry point directly. I want the project runnable according to `application` plugin without Docker too and for example give paths to the application via the start script and so on. I could of course also make Docker case specific logic, but it wanted it consistent, also because I develop and test with the application version and only have it in the Docker container for easy distribution and management, so I wanted it as similar as possible. So I basically ignored all files added by Jib, added the files "again" via extra directories and created layers as I wanted.

That would have been acceptable, if there would not have been this stupid version check and the inflexibility of the developers

&gt; Oh I didn't know the bmuschko plugin could do tar.gz I thought it only built against a docker daemon
&gt; 
Maybe you got me wrong. I have two tasks, one that builds the image on the daemon ANDA second that saves it to tgz. Both tasks from his plugin.

Ah OK. What is the version check thing? Thanks for going through this, it helps me know what to look out for.

I did same as you regarding files and start scrpts

As I said, I wanted to use a Java 8 base image for a Java 17 project as it is significantly smaller and Jib doesn't allow it as described above. I could of course have worked around that too by creating another Gradle subproject just for assembling the Docker image that is not a Java project, but at that point I was sick of jumping hoops just to make Jib happy and just accepted that it is only suitable for small standard projects and not if you need flexibility

Hmm OK. I don't think our use case would be effected by that. We are using jdk11 base images fir our java 8 and java 11 projects, but with jib we are also supporting a custom runtime built with the beryx plugin, so we use a base image with no jdk for that mode

If you don't need font support, that's probably fine. Otherwise you need a custom base image for example, as described above. :slightly_smiling_face:

Yeah we have some custom base images we use fir certain projects, but its still jdk11 so all our java 8 and 11 projects are fine with it

We only have one 17 projects so far and we use a jdk17 base image for that one

If you have custom base images, the version check does not affect you anyway, only some known base images are checked

Ah OK. That does seem like a weird feature though

Well, it is a shoot-yourself-in-the-foot protection, so that you do not try to run a Java 11 program with a Java 8 image and similar. The check is great generally, if it just were disableable where not applicable.

Generally good thing for almost any checks. Otherwise it will always try to bite for some corner case or another.

This is a variant resolution problem. The rest of the message should indicate the attributes looked at and why both variants match. It should also indicate which extra attributes do exist.
Unfortunately the Kotlin dependencies have a rich model that sometimes does not have a sane default in non Kotlin plugins enhanced projects.

Your solution will most likely require adding a specific attribute to that dependency or to the configuration resolving it. A capability fix does not seem like the right solution.

See <https://docs.gradle.org/current/userguide/variant_model.html#sec:variant-select-errors>

Adding an attribute to a dependency is similar to what’s done on a configuration, except that you do it inside the dependency block:
```implementation("foo:bar:1.0") {
    attributes {
        // ...
    }
}```

Thanks, that was the actual reason. Both had exactly the same attributes except one named `ui` . Weirdly, only the skiko variant for android has the UI attribute set to "android", but the skiko variant for awt did not have that attribute.
That's why I searched how to ask for an attribute to *not* be present, but I couldn't find a solution for that.
Then I found out that if I ask for a value of this attribute which does not even exist, Gradle uses the variant which does not have the attribute set, which in my case was the correct one. So I got it to work now, but it is just a workaround at the moment.

Perhaps check out the Nebula resolution rules plugin, specifically creating custom rules (JSON files) to reject, deny, substitute as appropriate.  That’s a layer over the underlying Gradle APIs that can do the same thing.

hmmm… are dependency substitution rules idempotent/recursion safe? Seems like the friendly way to do this is to declare that the “banned thing” should be substituted for by the internal “blessed thing”?

yea.  depends on the specifics - replace with a “good” version, substitute with a replacement, or outright fail.

regarding how to implement, my first instinct would be to reach for:
```configurations.all {
  incoming.beforeResolve { deps -&gt;
    //some logic that interrogates deps
  }
}```


but I’ve been burnt by trying to do clever things in beforeResolve before…

I appreciate the ideas, guys :slightly_smiling_face:

i have done
```project.configurations.findByName(
                    "implementation"
                )?.dependencies?.any { it.name == "library-name" } ?: false```

Technically speaking, even if you look at first level dependencies, you will not know if they were declared in a build script or somewhere else (e.g in a plugin).

Besides that you should usually never use `gradle`, but always `gradlew` to run a Gradle build to make sure it is ruin with the correct Gradle version, your problem has nothing to do with Gradle. Your build runs an external processes that exits with non-0 exit code which usually signals a failure.
It is uncommon that your processes did not print an error, but maybe he didn't use the streams appropriately. Try running with `-i` to maybe get the actual error message.

It is a configuration of the Kotlin Gradle plugin, that serves for resolving Kotlin metadata.
The configuration extends some `api` and `implementation` configurations from "fragements", whatever that is.
Obviously where those dependencies are declared and thus inherited from, the BOMs defining their version seem not to be declared too.
So when it is tried to resolve those dependencies, it fails as no version information is defined.

ah! yes, so it seems to be happening because i have:

```dependencies {
    // Import BOMs as gradle platforms
    annotationProcessor(platform(libs.spring.boot.bom))
    implementation(platform(libs.spring.boot.bom))
    implementation(platform(libs.fundamentals.bom))
...```
which results in them being available in `implementation`/`testImplementation` configurations, but _not_ in `runtimeOnly`/`testRuntimeOnly`

to avoid the error i can do
```    runtimeOnly(platform(libs.fundamentals.bom))
    runtimeOnly(platform(libs.spring.boot.bom))```
but is there any reason to _actually_ do that? the expected version seems to be resolved at runtime no matter what the dependency configuration reports

if so… is there any reason _not_ to follow the proposed solution <https://discuss.gradle.org/t/is-it-good-practice-to-apply-a-platform-dependency-to-all-configurations/37817|here>

```subprojects { // assuming we only have Java sub projects
   dependencies {
      configurations.each { add(it.name, platform(project(':my-platform'))) }
   }
}```

&gt; but is there any reason to _actually_ do that? the expected version seems to be resolved at runtime no matter what the dependency configuration reports
&gt; 
I have no idea what this configuration is used for, you need to all the Kotlin guys, but I'd expect that it is needed for something or it would not be there.

&gt; if so… is there any reason not to follow the proposed solution here
&gt; 
Multiple, for example `.each` only handles the currently existing configurations, `.configureEach` or .`all` would also handle ones added later. And more important almost any usage of a `subprojects` or `allprojects` block is bad for multiple reasons like introducing project coupling which defeats more sophisticated features like parallel execution and configuration cache, and it makes the build harder to maintain and understand.

i guess it’s a more general question outside of the specific kotlin-involved use case, or even the subproject bit…

if i want to manage versions of transitive dependencies (i.e. via a platform). is there any strong reason to prefer adding it to each configuration manually, vs. using something _like_ the below to apply it across all configurations. It seems like the very fact one is trying to manage transitives indicates that 99% of the time one would want them to be consistent across configurations
```configurations.configureEach { 
   add(it.name, platform(project(':my-platform')))
}```

i.e. do:

```dependencies {
    configurations.configureEach {
        add(this.name, platform(libs.spring.boot.bom))
        add(this.name, platform(libs.fundamentals.bom))
        add(this.name, platform(libs.spring.cloud.bom) )
        add(this.name, platform(libs.spring.boot.admin.bom))
        add(this.name, platform(libs.spring.cloud.bom))
        add(this.name, platform(libs.resilience4j.bom))
    }```
vs. say
```dependencies {
    annotationProcessor(platform(libs.spring.boot.bom))
    implementation(platform(libs.spring.boot.bom))
    runtimeOnly(platform(libs.spring.boot.bom))
    implementation(platform(libs.fundamentals.bom))
    runtimeOnly(platform(libs.fundamentals.bom))
    implementation(platform(libs.junit.bom))
    implementation(platform(libs.kotlin.bom))
    implementation(platform(libs.resilience4j.bom))
    implementation(platform(libs.spring.boot.admin.bom))
    implementation(platform(libs.spring.boot.bom))
    implementation(platform(libs.spring.cloud.bom))
}```

IMO until dependabot gets some fundamental changes to how it works with Gradle, it'll be unsuitable for most general Gradle projects
<https://github.com/dependabot/dependabot-core/issues/1164|https://github.com/dependabot/dependabot-core/issues/1164>

Thanks, interesting to see the issue. Seems to have gone silent for 6 months?

Don't suppose you have a view on renovate?
<https://www.mend.io/free-developer-tools/renovate/>

it has the same core issue, in that it attempts to parse the build scripts itself, which means it cannot understand plugins and other build logic. it looks like it does attempt to handle version ranges, but I don't have any experience with how well it does so

I went with Renovate over Dependabot where I work. Works just as well, supports version catalogs and supports custom locations for dependency files. As mentioned though, won’t help you with that problem

dependency constraints. For example
```dependencies {
    constraints {
      // Some plugins (e.g., Paparazzi) try to quietly upgrade the version of AGP we use.
      classpath('com.android.tools.build:gradle') {
        version {
          strictly '7.1.2'
        }
      }
    }
}```
(that's almost exactly code we have in our repo)

hmm, is this Gradle 7+ only? getting `Could not find method classpath() for arguments`

nvm, user error - replaced `classpath` with `testImplementation`  and it seems to be working  - need to see if I can use minimum version instead of a strict one now. Thanks

yeah, sorry, should have been more clear on the context. That snippet was pulled from a `buildscript` block

google "gradle rich versions" or something like that and you'll see the options available