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

Gradle Community

Looks like I'm still getting that error even after setting `-jvm-target=17`

kotlin-dsl sets jvm target to 8 because that's what Gradle targets

Is there any plan on the roadmap to update that?

I don't know if it's anywhere on the roadmap for Gradle to move to requiring Java 11 to run

you can override it via
```kotlinDslPluginOptions {
    jvmTarget.set("11")
}```
though, your plugin will then fail if run on an older JVM of course

Oh interesting, never knew about that extension, thanks

I am not on the Gradle team and cannot speak to whether this pattern will continue, but for reference:
Gradle 3.0 (2016-08-15) dropped support for running on Java 6 (last public update 2013-03)
Gradle 5.0 (2018-11-26) dropped support for running on Java 7 (last public update 2019-07)
Java 8 will continue receiving updates at least until 2026-05

```project.getLayout().dir(regularFileProperty.getAsFile().map(File::getParentFile))```


That gives a `Provider&lt;Directory&gt;` but I need a `DirectoryProperty`

oh right, sorry. wrap it with a directoryProperty like so:
```project.getObjects().directoryProperty().value(Provider&lt;Directory&gt;)```


there might be a simpler way though :thinking_face: this is rather verbose

It also causes issues with the configuration cache. I don't have the exact error in front of me, but it is related to calling `map` before the task runs. Although that may be the fault of the API I'm calling.

Perhaps you should avoid the `getAsFile` and use a mapper there as well, that way the entire chain should be safe to use, I think.

Also the consumer expecting `DirectoryProperty` is probably badly designed or could even be called buggy. It should accept instead a `Provider&lt;Directory&gt;`, then it would also accept `DirectoryProvider` and `DirectoryProperty`.

that shouldn’t be necessary.  `DirectoryProperty.set` is overloaded with variants taking `Directory` and `Provider&lt;Directory&gt;`

&gt;  Also the consumer expecting `DirectoryProperty` is probably badly designed or could even be called buggy. It should accept instead a `Provider&lt;Directory&gt;`, then it would also accept `DirectoryProvider` and `DirectoryProperty`.
The reasoning I got from them is:
```the problem of Provider&lt;Directory&gt; is that we cannot set the location ourselves which we want to do in order to avoid accidental overrides with 2 tasks outputing in the same location. That's why we use DirectoryProperty.```
&gt; Perhaps you should avoid the `getAsFile` and use a mapper there as well
Here's what I ended up with:

```objects.directoryProperty().run {
  fileProvider(
    task.output.map { outputFile -&gt;
      outputFile.asFile.parentFile
    }
  )
}```
How can I avoid calling `asFile` here?

the build works locally and packages the jar correctly. could a reason be regarding different OS ? pipeline is on linux while local machine is on windows

```/build/classes/java/main', not found
build/resources/main', not found```
this is what I get from logs on the jenkins machine. however my whole point was to package a module without main class. any ideas ?

Stuck?  Or not including correct files?  The . In the from is sketchy.  Should use project.layout.projectDir if that's the intent.

even then, that will grab a bunch of stuff you may not intend - build directories, etc.  If it’s a specific folder would suggest specifying that (or a set of folders).

Hi Chris ! Thanks a lot for answering. So yes, it does get stuck, locally it outputs same logs but packages everything. Also, my intention is to grab everything. I'll try using your suggestion

ok.  are you _really_ sure you want _everything_?  There’s transient build stuff in `build`, gradle caches in `.gradle`, the gradle wrapper etc in `gradle` etc that are unlikely to be of interest, and may become quite large (depending on your project).

I was thinking that I may need everything since some classes have dependencies - but I guess that's just build.gradle. After applying your suggestion, my pipeline is still stuck on the jar task. What's really confusing to me is that, if I leave jar { enabled = true} pipeline finishes with no issue, however that won't grab anything except for the manifest. as soon as I replace the enabled line with from and include, pipeline hangs on the jar task, whereas local build create a jar with everything (96kb)

yea.  it’s likely running out of memory.  in any event, that isn’t the right way to solve the problem.  You’re looking for a shaded jar (to include the dependencies).  To do that:
1. Leave the jar task as-is to create the base jar (compiled Java files &amp; resources);

2. Use the shadow plugin to add in the dependencies (and likely relocate their packages to avoid conflicts with consumers of your jar)

Would triple check that you _really_ need a shadow jar - they’re usually a last resort due to side-effects etc.

my goal is to: 1) have a flyway helper class inside testFixtures (which has flyway dependency) 2) have an sql folder with migrations 3) package those things so that I can consume the helper *with migrations* . I've managed to do this successfully with the above jar config and publish to local maven repo. sadly now PR is failing on the pipe even though size of jar is quite small (or so I think). sorry if I drifted off topic, quite new to all these things

another issue is the jar-task as is creates an almost empty jar (probably because I have no main directory / class)

Typical project layout for that would be:
• src/main/java - where your helper class lives;
• src/main/resources - where your SQL migration files live
…from that the regular `jar` task will bundle those up.  Consumers of that jar will transitively pull in flyway.

hmm , I guess I've overthinked everything with testFixtures. Will try your layout !

`testFixtures` is another source set which could also be used:
• src/testFixtures/java
• src/testFixtures/resources
…that would be used when distributing test fixtures, for consumption/execution in tests in other projects.

<@U02S31Y7J2K> you were completely right about the memory. As soon as I've dropped some useless stuff build passes on pipeline. And thanks for all the suggestions. I owe you a beer !

also: is it valid to do the aggregation _IN_ the rootProject? or does it have to be a siblling?

that is given the below
```build.gradle
module1/build.gradle
module2/build.gradle
test-results/build.gradle // must this exist?```
can i apply the `test-report-aggregation` in the top level `build.gradle` and aggregate there, or is there a reason that it really _should_ be in a separate module like `test-results`

Hello,
I am using Gradle’s “org.gradle.test-retry” plugin in order to rerun failed tests.
The grand idea is to enable trace logging only for those tests that have failed and are getting rerun.
The problem is, from what I understand, that the retry plugin forks another vm for the failed tests internally and I am unable to pass environment/system property telling the test code to enable tracing.
Any ideas how to enable trace logging only for the failed tests are very welcome :slightly_smiling_face:

Figure it out by using `--gradle-user-home` via this post <https://blog.jdriven.com/2021/11/reuse-gradle-build-cache-on-gitlab/>

Gradle template use the env var GRADLE_USER_HOME <https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Gradle.gitlab-ci.yml#L20>

If you think it could be due to cache ,  then perhaps running with `--rerun-tasks` or with build-cache disabled may help confirm that? But this most probably is a convention used by the task/plugin responsible for publishing. What version of AGP and gradle are these?

I’d also expect more support on this in <#CJYS1DAP5|> ..Since android’s artifact publishing is a  can of worms by itself :slightly_smiling_face:

This is for AGP `7.1.2` and Gradle `7.4.2`
---
Rerun tasks and no build cache did not work, will try a nuke nuke option now :cry:

Ah okay..~There were publishing  bugs in AGP prior to 7.2.1~ . Disregard that, 7.1.2 has the fixes.

I’ve successfully created aar artifacts (with much lesser custom code) with AGP 7. I imagine you are creating an aar here?

Are you using the new publishing api ?(<https://developer.android.com/studio/publish-library>) .

So… nuke options works!

Removing `GRADLE_USER_HOME/caches` is not, but removing `GRADLE_USER_HOME/.tmp` is!

I think it’s related to the artifact transform but I’m still not familiar with it.

&gt; Are you using the new publishing api ?
Not yet, but we have this on other branch :smile:

For now, we disable the automatic component generation

Oh..TIL about the `.tmp` directory…what does that contain ?

Not really sure, I check the directory again after build success but the directory is empty. But after deleting that, `detachedConfiguration` starts running again :thinking_face:

I didn't try that yet, but I'd guess `substitute(project(":foo")).using(module("foo:bar"))` and then having a composite build producing `foo:bar` could work

:party-gradlephant: Ohhhhhhh that is a workaround I guess, let me try

Haha I tried, it did not work, the dummy foo:bar is not found by gradle. Anyway, thanks <@URQ797WRW> :tada:

Why dummy? Don't use dummy. I said use the one the the included build produces.

It will of course not work with the dummy coordinates unless you add a manual substitution rule for it on the build include

Yes I added a manual substitution rule for composite build ~

Better try with the actual coordinates. But I fear it will also not work.

So there are 2 substitution, project(“:foo”) to module(“foo:bar”) for all subproject in root build.gradle.kts, then module(“foo:bar”) to composite build project(“source”) in settings - includeBuild { dependencySubstitution { } }

Within `includeBuild(...) { dependencySubstitution { ... } }`?
That will of course not work

Well, maybe it cannot work, I don't know, was just an idea.
As I said, never tried that.

It is shared for that task in any project, but it can be accessed concurrently for multiple tasks, except if you specify `maxParallelUsages.set(1)`

My idea is to use it for Docker compose, we have tests in a lot of projects using it, and that way they can use the same instances, and as a bonus I can control concurrency

No, of course not.
You are talking about hens and eggs.
The build script defines how to build that plugin project that has the plugin code as production code.
You cannot have the plugin code in its build script.

Actually, you can, but only with the `kotlin-dsl`. You define your plugin as script plugin instead and then you apply it in your own build script. It will be compiled twice and everything needs to be defined inside the script (with all the downsides), but now you can.

I don't get what you mean. If you define it in a script plugin that you apply in the build script, then it is not defined in the build script which was the question.

It depends on what the goal of the OP is. If the goal really is to _just_ define in the build script, then, yes, that's simply impossible (and makes little sense).
However, if the goal is to build a plugin that is also applied to the current build (common desire) then this is possible in the way I explained. Hacky, but it works.
`build.gradle.kts`
```plugins {
    `kotlin-dsl`
}

apply(from = "src/main/kotlin/my-plugin.gradle.kts")```
`src/main/kotlin/my-plugin.gradle.kts`
```// do something```

Yes my goal was to define it within build script for a very tiny task so it could be visible outside. So, the answer is a NO.

<@U01A244DYUF> I could probably use this hacky way for manual testing

I do see that if the plugin is defined inside `buildSrc/src/main/kotlin/myplugin.kt` then it can be applied within the build script of the same project.

Ref: <https://docs.gradle.org/current/userguide/custom_plugins.html#sec:packaging_a_plugin>

I had asked myself the same in the past. Whenever Gradle docs talk about subprojects, they seem to only refer to one level below the root project.

They work just fine. Although when you `include(":foo3:bar1")` it implicitly declare `include(":foo3")`.

The "conventional name" is still "multi-project build".
There is no distinctinction and nothing special about how deep the project tree is nested.

I heard them called nested projects, nested subprojects or just projects/subprojects since they're not any different then when you use flat directory structure.

Sorry if this gets slightly off-topics, but I also have wondered (but never tested) whether both the `root` and `foo3` projects could have `settings.gradle` files that each only include their direct dependencies, but then still from the root directory you could refer to `:foo3:bar1`. That would be very convenient, but I guess it does not work...

A settings script is for a build, not for a project
If you want it like that, you have to make `foo3` an included build

`settings.gradle[.kts]` is only for root of the build but you could compose them using `includeBuild`

Note that behaviour is the same with a composite

Yes, because you are invoking the `build` task of project `:A`. To fulfill the requirement of `:A:build` , Gradle only need to compile `:B` not test. You should use `./gradlew build` instead to build everything or `./gradlew :A:build :B:build` to build both project.

mmh ok, still seems awkward to me. I would expect `A:build` to depend on `B:build` and not `B:compile` ; I would expect my build to check whether my compiled dependencies pass tests when their sources have changed. For a composite build, it would induce that if I want to build or deploy part of my application, it is not safe to run build only on part of the composite (I could indeed specify every deps and transitive deps on command line, but if I’ve got many of them, it is error-prone).
Is this design only about performance? I hardly imagine a use-case of building an application with silenced failing tests on shared code for instance

At least for Java project there are also `buildNeeded` and `buildDependents`  that might run what you want:
<https://docs.gradle.org/current/userguide/java_plugin.html#lifecycle_tasks>

It's not actually build that depends on B's compile but build that depends on the current project's assemble which depends on the jar which depends on compile which depends on the api of B. It's a matter of what the lifecycle task means for the project. Each plugin reference page should have this information.

Gradle is designed to avoid work wherever possible.

To build `A` what is necessary are the classes of `B`.
Given `B` applies the `java-library` plugin, building `A` does not even trigger building the `jar` of `B`, but only compiling its sources to classes as that is all that is necessary to compile the classes of `A`.

If `A` is for example applying the `application` plugin and you run its `build` task, then the `distZip` and `distTar` tasks also need the `jar` of `B`, so also the `jar` is built, but still no tests as these are simply not necessary for the requested task.

But Gradle is convention-over-configuration, meaning it has sane conventions that the developers deem good for the average case, but enough flexibility to make a build however you like it. So if you want `A:build` to depend on `B:build`, declare it. Or if you want to depend `B:jar` on `B:check` so that tests and other check tasks are always done before the `jar` is build, declare it.

The defaults are simply chosen to avoid work wherever possible, so that a developer build can finish as fast as possible. Of course for the "price" of then needing to invoke what you want to do like  `gradlew build` to call the `build` task on all projects and thus also the `check` tasks, or `gradlew check` to call the check tasks on all projects.

<@U02DF9JDXJM> Yes that is a good point and is somehow similar to maven options also-make and also-make-dependencies; anyway I use Kotlin. I believe that would be nice built-in Gradle features.
<@UBTK9PLRM> <@URQ797WRW> Ok, got it! I’ll add dependencies between tasks to get the workflow I would like ; I hope that will not be hard to maintain, or I might find/write an equivalent to buildNeeded/buildDependents of the java plugin.

Thank to you all :slightly_smiling_face:

This should do it:
```tasks.withType&lt;KotlinCompile&gt;().configureEach {
    kotlinOptions {
        jvmTarget = "17"
    }
}```

Does that affect the target that Gradle itself uses? i.e. I thought that affects how your Kotlin code is compiled, not how Gradle compiles the Kotlin code from the script.

yes.  any Kotlin compilation will use that.  You can target a specified task if need be:
```tasks.named&lt;KotlinCompile&gt;("compileKotlin") {
    kotlinOptions {
        jvmTarget = "17"
    }
}```

oh, I see what you are asking - for Gradle kts scripts, not for what Gradle is compiling.  That requires `kotlin-dsl` and a different setting, one sec…

```configure&lt;KotlinDslPluginOptions&gt; {
    jvmTarget.set(kotlinPluginJvmVersion.toString())
}```

The OP is asking about doing it without the `kotlin-dsl` plugin though.

hmmm.  Unclear if OP is asking for Gradle kts (plugins, scripts, etc) or for a Kotlin app/lib.  If there is anything of significance for Gradle build (build-logic composite include, etc) should be using `kotlin-dsl`.  Definitely don’t want to mix `kotlin-dsl` into a Kotlin app/lib, that causes all manner of problems.

Maybe just including a `compileOnly` dependency on `gradleKotlinDsl()` is enough? That's what `kotlin-dsl` does

No, definitely don’t do that.  Kotlin DSL depends on Gradle’s embedded Kotlin version, which is likely different than used for Kotlin app/lib, causing all manner of problems.

This (or variations / subsets thereof) i the anti-pattern to avoid.  A project can’t be both a Gradle Kotlin DSL/plugin (`kotlin-dsl`) AND a Kotlin app/lib (`kotlin("jvm")`) at the same time.

```plugins {
    `kotlin-dsl`
    kotlin("jvm") version "1.5.30-M1"
}```

So a Kotlin gradle script for a Kotlin app/lib can't change the jvmTarget from 1.8?

Yes.  That’s this snippet:
```configure&lt;KotlinDslPluginOptions&gt; {
    jvmTarget.set("17")
}```

Not aware how to effect that w/o `kotlin-dsl`, however best practices are to factor out imperative code into plugins, tasks, etc - place those in a build-logic composite project (or the older, less ideal buildSrc) with `kotlin-dsl`.

So the offending inline function call should be moved to a plugin or task, and that project should set the target to 17 with `kotlin-dsl` applied?

OP nowhere mentioned anything about Gradle logic. I'd say Chris first answer was exactly what he is after from what he asked.

If you do develop Gradle logic and change the jvm target to anything but what `kotlin-dsl` sets by default, you have to be aware that you are effectively raising the minimum Java version needed to run the Gradle build to that version which usually is highly undesireable.

I'm assuming it's about gradle logic because they specifically asked about not applying `kotlin-dsl`.

&gt; usually is highly undesirable
&gt; 
So it would be fine if it were an internal app that is already committed to using that version of Java?

The important distinction is, the Java you use for your production code, vs. the Java you use for running Gradle. If you do that to Gradle logic, all builds that use this Gradle logic has to be run with at least that Gradle version, independent from what you use for your production code. Optimally you use the JVM toolchains feature to also separate this for your builds.

But yes, if it is internal build logic and everyone and everything running these builds runs them with at least that Java version and that Java version is supported by your Gradle version for running Gradle, it should be fine I think.

&gt; I'm assuming it's about gradle logic because they specifically asked about not applying `kotlin-dsl`.
I'm assuming it is *not* about Gralde logic because they specifically asked about nto applying `kotlin-dsl`.
What should be the problem to apply if it is for Gradle logic?
For me it makes more sense that it is for non-Gradle logic bug by googling OP just found solutions involving `kotlin-dsl` which he does not want to use as it is not for Gradle logic.

But only OP can tell. :slightly_smiling_face:

&gt; A project can’t be both a Gradle Kotlin DSL/plugin (`kotlin-dsl`) AND a Kotlin app/lib (`kotlin("jvm")`) at the same time.
So this is pretty much what I was trying to do but that doesn't work

&gt; I'm assuming it is *not* about Gralde logic because they specifically asked about nto applying `kotlin-dsl`.
&gt; What should be the problem to apply if it is for Gradle logic?
It is for Gradle logic but is a problem because of the above

But this is for internal use only anyway so I'll try the solution posted while keeping your warning in mind :slightly_smiling_face:

Thanks for your help

if it’s for Gradle logic, remove `kotlin("jvm")` and use `kotlin-dsl`.  Doable?

No, because it is for a Kotlin app so can't remove that

Perhaps move the Gradle logic to build-logic included project (or the older buildSrc).  That way you can separate the Gradle logic / build from the app build.

Well, that's always the problem you have with transitive dependencies.

If you want to minimise this for your own interdependent projects, I guess publishing a platform and / or version catalog as lib is probably one of the better options, and then all those projects can depend on this platform and / or version catalog.

This is a great idea! Reading through <https://docs.gradle.org/current/userguide/platforms.html>

We have developed Pierrot for exactly this problem with the internal libraries. One of the functions is to bump the internal library versions and to do plan upgrades (e.g. you can't simply bump JUnit from 4.x to 5.x nevertheless Snyk or Dependabot is telling you).

We are keeping the versions in `gradle.properties` so it's easy to run text replacements. And as <@URQ797WRW> suggested we use BOMs to force the versions.

<https://agorapulse.github.io/pierrot/#_replace|https://agorapulse.github.io/pierrot/#_replace>



I have it! :slightly_smiling_face:
`your-domain/scans/roi-volume`

here is the catalog definitions: <https://github.com/kotest/kotest/blob/published-catalog/build.gradle.kts>
Published locally using `./gradlew publishKotestVersionCatalogPublicationToMavenLocal`
Imported in another project using:
```dependencyResolutionManagement {
   repositories { mavenLocal() }
   versionCatalogs {
      create("kotest") {
         from("io.kotest:kotest-version-catalog:5.5.0-LOCAL")
      }
   }
}```


Created a small reproduction repository of the problem here: <https://github.com/Kantis/version-catalog-problem/tree/main>

depends on the IDE, but currently IDEA doesn't have any good way: <https://youtrack.jetbrains.com/issue/IDEA-252328|https://youtrack.jetbrains.com/issue/IDEA-252328>

Thank you, this confirmes what I observed: Intellij does its own thing which cannot be influenced...

I don't think so, only at the respective tasks afair.
But I'd recommend you use JVM Toolchains feature instead to decouple the Java version running Gradle from the Java version used to build and run your production code.

Hi. I have centralized the repository definition under `dependencyResolutionManagement` . Is there a way I can access the *custom-repo* in the `publishing` block in a subproject?
The intention was to avoid redefining the custom repo.

would that be
<https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:ignoreFailures>

?

with that boolean how are you going to know if the task is failing due missing tests or because the test is failing?

well, let me restate. I need to validate what that boolean does. It looks like it disables internal task validations. I still want the task to fail if the test fails

<https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/testing/TestFilter.html#setFailOnNoMatchingTests-boolean->

build scan is here, if that's relevant: <https://scans.gradle.com/s/2vsa4sbq6er2m/activate>

any idea what I could be doing wrong? I don't even use java anywhere in my project

What you get from `val libs = extensions.getByType&lt;VersionCatalogsExtension&gt;().named("libs")` is the full version catalog. You get both, the libs and the plugins from it, but both only stringy.

Type-safe accessors you only get using a hack I detailed at <https://github.com/gradle/gradle/issues/15383>

This does seem to kinda work, only gotta figure one more thing to try this out. The way we apply these in a normal build.gradle.kts is with this syntax `alias(libs.plugins.xx)` but this `alias` function doesn’t seem to be available in my convention plugin configuration. Is there something I can do there too, like some way to use the `libs.plugins` in a `apply()` instead?

I guess I can potentially do `apply(libs.plugins.xx.get().pluginId)` but then rely on the version of it being applied on the root build.gradle with `apply = false` but that doesn’t sound that great either :thinking_face:

Hard to say wihtout more information.
For example if you use precompiled script plugins for the convention plugin, it should be the same.
If not, then you probably have to do it like shown.
But you don't depend on the plugin bein added to the root build script, but through having the plugin as dependency of the convention plugin it is already in the classpath.

Getting a bit of gradle keyword overload here tbh :sweat_smile: Kinda hard to follow what you mean, but I’ll simply play around with it and see where it goes. Thank you a lot for the help!

Looking at the docs of the `inline fun &lt;reified T : Any&gt; Project.the(): T` function, I read
```/**
 * Returns the plugin convention or extension of the specified type.
 *
 * Note, that the concept of conventions is deprecated and scheduled for
 * removal in Gradle 8.
 */```
Since this is to be removed, is there something coming in to replace it? Seeing it made me double think if I even want to go that approach if I must revert it in gradle 8 anyway.

Only conventions are deprecated, not extensions.
And what is called "convention" there has nothing to do with "convention plugins", that's not related actually.
Just unlucky wording.

Damn there’s a lot of keywords one needs to be familiar with to have discussions about gradle, it’s quite a challenge for someone newer to it. Thanks for taking the time to clarify this to me too though, I really appreciate it!

Yeah, don't worry. That's the same with most universes. :-)
Comes time, comes knowledge of terms.

Yeah, got <https://github.com/HedvigInsurance/android/compare/develop...gradle/remove_cross_projects_configuration|this diff> actually, it all seems to work! For some context, I went into this rabbit hole trying to apply the tips provided <https://github.com/gradle/android-cache-fix-gradle-plugin#applying-the-plugin|on the android-cache-fix-gradle readme> to not use subProjects but use my convention plugins to apply this plugin :sweat_smile:
I hate referring to things with their string, I think I’ll keep this way, and hopefully there will be a more standard way to do this soon without this as you called it “small work-around”.

`extensions` is <https://docs.gradle.org/current/userguide/platforms.html|documented> as being reserved.

From the wording there, I'd take it using just `extensions` as the entire alias would be unsupported, but `extensions-foo` (extensions as first subgroup) should be fine?

unlikely, as `-` is a separator, leaving `extensions` as an alias.  Hard to know without testing it.

Yeah it's not working in my sample repo :) 

The message does not tell you it didn't find a configuration.
It says it couldn't choose between these two and didn't consider the third one.
If you look at output of `:sub:outgoingVariants`, you see that there is a `runtimeElements` primary variant with two sub-variants `classes` and `resources` for things that don't need a jar, but just the compiled classes and / or resource files.

First it tries to find a matching variant.
The primary `runtimeElements` variant does not match because of the `transformed` attribute being set to `false`.
The secondary variants do not have that problem because their `artifactType` is not `jar` so you didn't set it.
But now it has two equally matching variants, `classes` and `resources`, where all requested attributes are not present (`transformed`) and all present attributes are not requested (the standard JVM ecosystem properties as documented).
At this point in time the resolution fails as Gradle is unsure which variant to pick, as both would equally well fulfill the requirements without the need of doing any transforms and fails.

If you add the JVM ecosystem attributes - or at least `attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements, LibraryElements.JAR))` to resolve the ambiguity between the three of them - the secondary variants are ruled out as the attribute does not match, but the primary variant can - with the help fo the artifact transform - made matching the requested attributes and thus this one will be picked.

I see. This really should be better explained. I will check if that solves it.

I don't really know where I would set that attribute

I figured it out, but also - this requires that this is done on the whole configuration, couldn't that lead to issues if there is any dependency that isn't a jar?

Another thing I don't understand there is that clearly, gradle can choose the variant if there is no transformed attribute being required. Then why can't it choose the same one it would have used otherwise?

As I tried to explain, without the transformed all three match attribute-wise. One is primary, the others are secondary to it, so the primary runs over the secondaries.
With the transformed attribute, the primary would match with one transformation, the two secondaries would match without transformation. So shorter transformation chain (0) wins over longer chain (1), and now you are left with two variants that are equally eligible.

You can set attributes on the whole configuration, but you can also set them on a specific dependency individually. So if you would have a differently typed necessary, you can overwrite the attribute for that specify dependency.

But yes, those details are relatively complex and I also needed some time to wrap my head around it  to some extent. Still not always sure what happens.

I tried to set it in the dependency directly and getting `Mutation of attributes is not allowed`

tried this
```dependencies {
    newTestConf(project(":sub")) {
        attributes.attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements, LibraryElements.JAR))
    }
}```

&gt;  With the transformed attribute, the primary would match with one transformation, the two secondaries would match without transformation. So shorter transformation chain (0) wins over longer chain (1), and now you are left with two variants that are equally eligible.
So when there are unmatched attributes, gradle completely ignores the primary vs secondary variants and considers them all equally?

I... no longer understand how that syntax works. attributes≥attribute() doesn't work but attributes{attribute()} does

&gt; With the transformed attribute, the primary would match with one transformation, the two secondaries would match without transformation.
What why?

Wouldn't all of them require one transformation? Or am I missing something?

&gt; I tried to set it in the dependency directly and getting `Mutation of attributes is not allowed`
Not fully sure right now why, but if you instead write it like
```attributes {
    attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements, LibraryElements.JAR))
}```
it works fine.

&gt; So when there are unmatched attributes, gradle completely ignores the primary vs secondary variants and considers them all equally?
I'd tend to say "no", but I'm not sure what you try to say.
It is not ignored, but simply ruled out before it is checked.
Gradle tries to find a variant using attribute matching.
During this attribute matching, shorter transformer chain wins over longer transformer chain.
If in the result there is primary and secondary, primary wins.
&gt;&gt; With the transformed attribute, the primary would match with one transformation, the two secondaries would match without transformation.
&gt; What why?
&gt; Wouldn't all of them require one transformation? Or am I missing something?
No, with
```dependencies {
    artifactTypes.getByName("jar") {
        attributes.attribute(transformedAttribute, false)
    }
}```
You set `transformed` to `false` for all variants with artifact type `jar`.
Those secondary variants have other artifact types, you can see that when looking at `:sub:outgoingVariants`.
So those secondary variants do not provide the transformed attribute.
If you would set the attribute to `false` for those too, they would actually never be used, if `transformed` `true`is requested,
because you would have no transformation that can transform the attribute.

You could also register an attribute compatibility rule that says absent attribute is not considered as compatible if `true` is requested like
```class Foo implements AttributeCompatibilityRule&lt;Boolean&gt; {
    void execute(CompatibilityCheckDetails&lt;Boolean&gt; details) {
        if ((details.consumerValue == true) &amp;&amp; (details.producerValue == null)) {
            details.incompatible()
        }
    }
}

dependencies {
    attributesSchema {
        attribute(transformedAttribute) {
            compatibilityRules.add(Foo)
        }
    }
}```
then it would also not use the secondary variants.

By default an attribute is considered compatible if it is absent and the more attributes matched, the better the match.
With a compatibility rule you can change that.

You can find deeper details about the selection algorithm in the manual at <https://docs.gradle.org/current/userguide/variant_attributes.html#attribute_matching>

Now I think I finally understand it properly. Thanks for the explanation!

One last thing, hopefully: I wanted to do some more tests to confirm I understand it properly, and it seems like it's impossible for me to actually set the transformed attribute on the classes and resources variants

This is more for the sake of me copmpletely understanding how this all works.

I can see and it agrees with the expanation that I'm setting the transformed attribute only for artifact type jar. But seems like it's not even possible to set it on the other variants

Why not?
What did you try and what happened?

```artifactTypes.getByName("java-classes-directory")```
shows that there is no such artifact type. Trying to create it doesn't have any effect.

I also tried to confirm all this by just creating the AttributeCompatibilityRule but that also doesn't seem to have an effect - the compatibility rule is never called with producer value null

I tried the compatibility rule before I wrote it would work, so you probably made a mistake :slightly_smiling_face:

In the meantime I also ported the test script to kotlin (because I want help from the IDE) and this is what I'm trying with the compatibility rule <https://gist.github.com/Barteks2x/08aa7d750591c898118c9a86d75fe603>

There is also the really strange thing in that the entire situation doesn't happenm in the first place if I just specify the dependency on for example implementation and let gradle build the project - so gradle can resolve and run the transform just fine... but on a custom configuration it can't?

I can clearly work around the issue in multiple ways but what I'm seeing just still makes no sense to me

Somehow specifying the usage attribute to java-api in the configuration I'm creating also fixes it... but why?

oh because the others have java-runtime usage and that filters them out. But that still doexn't explain  any of the other things.

But I feel like specifying the standard java attributes for the new configuration is the "correct" fix

No idea about the artifact types of secondary variants, maybe that does not work or has to be done differently.
Never dived into that part yet.

&gt; In the meantime I also ported the test script to kotlin (because I want help from the IDE)
Imho always a good idea, I use Kotlin DSL exclusively nowadays.

&gt; so gradle can resolve and run the transform just fine... but on a custom configuration it can't?
I already explained that in the first post.
On `implementation` all the JVM ecosystem attributes are set - in this case especially `LIBRARY_ELEMENTS_ATTRIBUTE`, on your custom configuration they are not.

&gt; and this is what I'm trying with the compatibility rule
Ah, sorry, it seems by test was bad.
I added the compatibility rule but also had the `LIBRARY_ELEMENTS_ATTRIBUTE` on the dependency which made it work. :disappointed:

&gt; Somehow specifying the usage attribute to java-api in the configuration I'm creating also fixes it... but why?
Only one variant matches the attributes if you have `java-api` and that one can be transformed using the registered transform, so no ambiguity and it works.

&gt; But I feel like specifying the standard java attributes for the new configuration is the "correct" fix
Exactly

Actually it is neither a valid use-case, nor a premature optimization or optimization at all.

You are using `compileOnly` so it is not part of the runtime classpath. This way your convention plugin can only work if you manually (or otherwise) added the plugin to the classpath, for example with your `alias(libs.plugins.ktlint) apply false`.

But that line is then just a work-around for your broken convention plugin that does not properly declare its runtime dependency.

`compileOnly` is for things you need at compile time, but not at runtime. As you want to apply that plugin and also configure it using classes from it, you obviously *do* need it at runtime too.

One use-case where you could use `compileOnly` is for example if you have annotations that you need on the compile classpath so your code compiles, but that you do not need at runtime. Either because their retention is not `RUNTIME` anyway, or if they are there for consumers that request it and thus bring it to the classpath theirselves.

Amazing, I had totally misunderstood it then, so much I got wrong!

I think I still haven't grasped what's compile time and what's runtime in the context of Gradle. As I was thinking about it, compile time should be everything that happens before I launch my Android application, so like Gradle running, compiling the code, running all the Gradle tasks etc. Basically everything before my application is launched on my emulator. But it seems in the context of Gradle runtime is also when the build is running and configuring stuff right?

I think the takeaway is to never do `compileOnly` unless I am in that very particular use case, which I doubt will happen often if ever.

compile time and runtime has nothing to do with Gradle context.
compile time is when compiling the `.java` files to `.class` files.
runtime is when executing the `.class` files.
But yes, you usually pretty seldomly use `compileOnly`.

Fwiw, when you have annotations with `CLASS` retention, you'll probably want to use `compileOnlyApi` rather than `compileOnly`. `compileOnly` really only fits for annotations with `SOURCE` retention (it's older than `compileOnlyApi`, probably even older than `api` actually).

I don't agree.
`compileOnlyApi` (besides that it is only available with the `java-library` plugin) is for classes that need to be present
• at compile time
• and at compile time of downstream code
• but not at runtime
Downstream code should not need the annotation class on its compile classpath to compile against a class that has the annotation present.
`compileOnlyApi` is for real code that you need at compile time and in downstream code at compile time but not at runtime.
Actually I never hit a case where I needed it so far personally.

Don't forget static analysis (which btw can happen at `javac`-compile-time with tools like ErrorProne or the Checker Framework).

I guess if they understand a particular annotation for some meaning, they should bring it to the class path themselves?

They could *ask* you to add them to the classpath (`compileOnly`, but then also `testCompileOnly`, etc.) so they could check them when present in code from dependencies, or dependencies could declare them as `compileOnlyApi` so you don't have to care about what annotations are or might be used by your dependencies when you compile against them while using static analysis tools.
And don't forget the cases where the tools check annotations based on their simple name only (e.g. `@Nullable`, `@CheckReturnValue`, `@CanIgnoreReturnValue`, etc.), in this case a library defining an annotation in its own package but in a separate artifact wouldn't be correctly _checked_ unless all downstream projects are instructed to add the annotation artifact to their classpath; `compileOnlyApi` simplifies this.
Fwiw, Guava initially declared its annotation dependencies as `&lt;optional&gt;true&lt;/optional&gt;` in its POM (or was it `&lt;scope&gt;provided&lt;/scope&gt;`? or both? anyway, same end result) and switched to non-optional compile scope due to issues like that in downstream projects.
Put differently: annotations are part of your API, so put them in `api` or `compileOnlyApi` (or `implementation` if you're not using the `java-library`, but you really should use `java-library`) unless you have good reasons not to (`compileOnly`).

Hm, I see, thanks for the info, will play a bit with it

Hello/ i tryed to change my icon app and i receive this error is anybody knows what is my problme....

Not an Android guy here, but I'd say the error is pretty meaningful, isn't it?
I'd say you reference the resource `mipmap/ic_launcher` in your `AndroidManifest.xml` but it is not found.
If you need further help, I guess you should ask in some flutter or Android community, or at least in <#CJYS1DAP5|> or <#C03EM93810S|>, resp. post a link to this question there. :slightly_smiling_face: