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

Gradle Community

There’s some `afterEvaluate` going on for the `kotlin-dsl` Kotlin settings (<https://github.com/gradle/gradle/blob/master/subprojects/kotlin-dsl-plugins/src/main/kotlin/org/gradle/kotlin/dsl/plugins/dsl/KotlinDslCompilerPlugins.kt#L43|here>); you may need to wrap your settings in afterEvaluate as well, to run after that one.

Thanks, this does work in the Gradle Kotlin dsl plugin, but any chance to overwrite the Kotlin version and its options used by Gradle itself?

Okay, I don't think so. They are hardcoded here: <https://github.com/gradle/gradle/blob/da59fbd0db73df45e2c59b2aca7cda83d62bd89f/subprojects/kotlin-dsl/src/main/kotlin/org/gradle/kotlin/dsl/KotlinDslStandaloneScriptCompilationConfiguration.kt#L37>

Maybe adding `-Xskip-prerelease-check` would be enough.

That error means you have something invalid within `application { ... }`.
Unfortunately the error is not really telling what exactly.
I strongly recommend to use the Kotlin DSL instead of the Groovy DSL.
You immediately get type-safe build scripts, much better and more helpful error messages if you mess up the syntax like you did, and amazingly better IDE support if you use a proper IDE like IntelliJ.
If you don't want to, comment out all content of `application { ... }` and comment it in line by line or block by block to find out where you messed up the syntax.

You say I mess up the syntax, but the error was in one of the files gradle itself made

What file are you referring to?
Do you mean you use `init` and Gradle generated invalid files, or what do you mean exactly?

While I write recommend using the test suites plugin anyway, it is hard to tell from your abstract description, at least for me. Maybe you can knit an <https://stackoverflow.com/help/mcve|MCVE>?

test suites plugin seems to be what im actually looking for, ill get an mcve sorted as soon as i can, prob this week

it <https://github.com/alexanderankin/reproduce-multi-test-suite-visibility-bug/blob/main/build.gradle|doesn't> reproduce (edit: <https://github.com/gradle/gradle/issues/19645|solved>)

tbh i wasn't very hopeful, but at least it is a more concrete explanation of what i was seeing.

mystery solved, intellij plugin cannot comprehend multiple test suites depending on each other.

err, they half deprecated the property that would have configured test source directories...

not sure where to put this find so that it is discoverable by other people...

I guess that's a precaution that you do not do `useJUnit()` followed by `useSpock()` or similar. Which you currently can call but the effect will be unexpected. Fell into that exact trap a week ago.

Hmm, I have `useJUnitPlatform()` for all `Test` tasks (see <https://github.com/oss-review-toolkit/ort/blob/f6356723dbfc0d8bd9f44d7b4088373adfdd571d/build.gradle.kts#L318>), so shouldn't that also apply to the `funTest` tasks created via registering the test suite?

Looks like I'm basically running into <https://stackoverflow.com/a/70039080/1127485>, except that I'm not using a test's `options`... (knowingly)

Ah, it's actually <https://github.com/gradle/gradle/issues/23544>. Simply dropping `useJUnitPlatform()` fixes the issue :eyes:

Execution failed for task ':runClient'.
&gt; Process 'command ...jdks\corretto-17.0.6\bin\java.exe'' finished with non-zero exit value 1

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, whatever your `runClient` task is, I'd guess it is a `JavaExec` type task and what it called exited with exit value 1.
Gradle is just telling you that.
So debug whatever you run there and find out where it does not behave as you'd expect

And if it is not your code, maybe scroll up, most programs print something before they exit with non-0 exit code to actually tell what is wrong.

If you run in AS or IJ you might easily miss the actual error information due to this annoyance: <https://youtrack.jetbrains.com/issue/IDEA-226613/Gradle-build-on-failed-build-IDE-auto-focuses-and-shows-incomplete-error-message-which-makes-it-hard-to-understand-why-build|https://youtrack.jetbrains.com/issue/IDEA-226613/Gradle-build-on-failed-build-IDE-auto-focuses-and-shows-incomplete-error-message-which-makes-it-hard-to-understand-why-build 2> so you need to select a higher node in the tree to see the actual error details.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

also Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

look further. that is not related to your error, it just means that one of the plugins your build uses will need to be updated in the future.

anyone got this error on gradle 8?
```  A problem occurred configuring project ':accommodation:booking:accommodation_booking_impl'.
      &gt; Failed to notify project evaluation listener.
         &gt; com.android.build.gradle.internal.crash.ExternalApiUsageException: java.lang.NoSuchMethodError: 'void org.gradle.api.internal.file.UnionFileCollection.&lt;init&gt;(org.gradle.api.internal.file.FileCollectionInternal[])'        
         &gt; Extension with name 'generalFilters' does not exist. Currently registered extension names: [ext, filters, debugFilters, releaseFilters, stagingFilters]```


I'm contributing to a lib where we would like to create an integration-test using gradle testkit to apply the lib and run tests w/ gradle. (see <https://github.com/kotest/kotest/pull/3401#issuecomment-1429327833> for more context)

Is there any way to get the gradle runner to perform dependency substition using the composite build invoking the runner?

Well, maybe the issue is this one as I am creating a plugin in an included build

<https://github.com/gradle/gradle/issues/21467#issuecomment-1298817493|https://github.com/gradle/gradle/issues/21467#issuecomment-1298817493>

hello everyone, i need a hand with a little issue i have

i`m having this error and cannot resolve yet

FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Could not initialize native services.
   &gt; Failed to load native library 'native-platform.dll' for Windows 11 amd64.

* Try:
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

* Get more help at <https://help.gradle.org>

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, do you get more helpful information if you run with `--info` and / or `--stacktrace` and / or `--debug`?

sorry, my bad. Thanks for the outcome!

apparently is something wrong with the path

Caused by: java.io.IOException: The system cannot find the path specified

i`ll check the enviroment variables and created in the system and local too, if i use a VM or a Ubuntu on Windows gradle init run perfectly so, it must be some config that is not right

You mean this one? <https://blog.gradle.org/wrapper-attack-report|https://blog.gradle.org/wrapper-attack-report>

Also I could not find a #testing or equivalent channel in this slack, please let me know if there is a better suited channel for this.

Yeah the docs could be better. That's one reason why I did a bit of an overview here: <https://youtu.be/YJjNQJSaFww>

• The tests are executed in separate JVMs (Worker JVMs)
• Within one test tasks the JVMs are reused unless you set "forkEvery" to force the shutdown after a certain number of test classes
• If you set tests to run in parallel with "maxParallelForks" that is how many parallel JVMs will be forked for one test task
• "org.gradle.workers.max" is still respected and might lead to a lower number of Worker JVMs than defined in "maxParallelForks" 

Thank you, this does help clarify a few things. Would you also know what does the number on the test executor correspond to. Is that something like a pid for the test executor?

I think it's just a number that's incremented in the Gradle Daemon. So the first worker started for your build is 1 the next 2 and so on. But I am not 100% sure.

Simply modularizing the project is not a guarantee to faster builds.
Each module need to build all the other modules it depends before being built. Therefore, the key here is how each module depend in each other.
It needs to be modularized carefully so you limit the number of modules depending between each other, maximizing the amount of modules that can be compiled in parallel.

You can see your module dependencies graph as a tree, where the main app module is the root. Then, your goal is to reduce the heigh of your tree from the root to the leaves. Ideally 3-4 levels at most.

If you are not sure about your modules graph, you can use this <https://github.com/jraska/modules-graph-assert|plugin> (and I encourage you reading also its documentation, as it also has some recommendations to achieve what I was describing above).

And you are quite correct when you mention that each module comes with some overhead. So think carefully which modules make sense for your project and try to be lean, not abusing of modules with just a few files.

Do we mean overhead by configuration time or execution time also needs to pay this cost?
Yes we’re using that plugin and we’re making sure our current height ie 6 should not increase and also have rules in placed to avoid unnecessary dependency . But the point I’m making here let’s say you have 2,00,000 LOC in your app module and you create a new module out from app which has 10,000 LOC now the newly create module is taking 20-25 to compile but if you look at the build time of app module in gradle scan is not reducing. Ideally app module build time also should reduced by 20-25 sec.

Not an expert in how gradle compiles, but I don’t think the build times are comparable linearly in the way you expect.
The time building 10k isolated lines doesn’t need to be the same as building 10K as part of a bigger chunk of 200k. So if the new module is taking 25 sec, maybe you might just get 5 back in the main app module. It might be not significant step by step, but would be noticeable after some more modules are extracted.
At the end you need you are creating a more complex system, and you need to spawn other workers to build those modules, so they might need to catch-up and produce some duplicated stuff.

This should not be compared serially, but by having the modules gives the system the chance to run all of this in parallel. So even if the total computational time of all modules is higher, the total time of the whole build would eventually be smaller.

In any case, you will notice this benefit more for incremental/cached builds (where only a subpart of the modules needs to be built). This is one of the key reasons to modularize, as engineers working only in a module will just need to compile a subset of the project.

can you share the prints of `./gradlew build --dry-run`?

if `proto` is a `java-library`, `api` can consume its classes and resources without going through `proto:assemble`

```14:32:16: Executing 'clean build --dry-run'...

:clean SKIPPED
:api:clean SKIPPED
:proto:clean SKIPPED
:server:clean SKIPPED
:assemble SKIPPED
:spotlessCheck SKIPPED
:test SKIPPED
:proto:extractIncludeProto SKIPPED
:proto:extractProto SKIPPED
:proto:generateProto SKIPPED
:proto:compileJava SKIPPED
:proto:processResources SKIPPED
:api:extractIncludeProto SKIPPED
:api:extractProto SKIPPED
:api:generateProto SKIPPED
:api:compileJava SKIPPED
:api:processResources SKIPPED
:api:classes SKIPPED
:api:sourcesJar SKIPPED
:api:jar SKIPPED
:api:assemble SKIPPED
:api:findDuplicates SKIPPED
:spotlessInternalRegisterDependencies SKIPPED
:api:spotlessJava SKIPPED
:api:spotlessJavaCheck SKIPPED
:api:spotlessKotlin SKIPPED
:api:spotlessKotlinCheck SKIPPED
:api:spotlessCheck SKIPPED
:api:extractIncludeTestProto SKIPPED
:api:extractTestProto SKIPPED
:api:generateTestProto SKIPPED
:api:compileTestJava SKIPPED
:api:processTestResources SKIPPED
:api:testClasses SKIPPED
:proto:classes SKIPPED
:proto:sourcesJar SKIPPED
:proto:jar SKIPPED
:api:test SKIPPED
:api:verifyBreakingChanges SKIPPED
:api:verifyCyclicDependencies SKIPPED
:api:verifyDeniedModules SKIPPED
:api:verifyMajorVersion SKIPPED
:api:verifyDependencies SKIPPED
:api:check SKIPPED
:proto:assemble SKIPPED
:proto:findDuplicates SKIPPED
:proto:spotlessJava SKIPPED
:proto:spotlessJavaCheck SKIPPED
:proto:spotlessKotlin SKIPPED
:proto:spotlessKotlinCheck SKIPPED
:proto:spotlessCheck SKIPPED
:proto:extractIncludeTestProto SKIPPED
:proto:extractTestProto SKIPPED
:proto:generateTestProto SKIPPED
:proto:compileTestJava SKIPPED
:proto:processTestResources SKIPPED
:proto:testClasses SKIPPED
:proto:test SKIPPED
:proto:verifyBreakingChanges SKIPPED
:proto:verifyCyclicDependencies SKIPPED
:proto:verifyDeniedModules SKIPPED
:proto:verifyMajorVersion SKIPPED
:proto:verifyDependencies SKIPPED
:proto:check SKIPPED
:server:compileJava SKIPPED
:server:processResources SKIPPED
:server:classes SKIPPED
:server:sourcesJar SKIPPED
:server:jar SKIPPED
:server:assemble SKIPPED
:server:findDuplicates SKIPPED
:server:spotlessJava SKIPPED
:server:spotlessJavaCheck SKIPPED
:server:spotlessKotlin SKIPPED
:server:spotlessKotlinCheck SKIPPED
:server:spotlessCheck SKIPPED
:server:compileTestJava SKIPPED
:server:processTestResources SKIPPED
:server:testClasses SKIPPED
:server:test SKIPPED
:server:verifyBreakingChanges SKIPPED
:server:verifyCyclicDependencies SKIPPED
:server:verifyDeniedModules SKIPPED
:server:verifyMajorVersion SKIPPED
:server:verifyDependencies SKIPPED
:server:check SKIPPED
:gateOnAllTests SKIPPED
:api:jacocoTestReport SKIPPED
:proto:jacocoTestReport SKIPPED
:server:jacocoTestReport SKIPPED
:jacocoMerge SKIPPED
:jacocoTestReport SKIPPED
:check SKIPPED
:build SKIPPED
:api:build SKIPPED
:proto:build SKIPPED
:server:build SKIPPED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See <https://docs.gradle.org/7.4/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD SUCCESSFUL in 196ms
14:32:17: Execution finished 'clean build --dry-run'.```


<https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_classes_usage>

it can use the compiled classes and processed resources directly, rather than going through jar/assemble

I don't understand how that helps me in this case

My use case is that I have a task `findDuplicates` which examines the contents of the jars files to check whether there are files with the same name in all the different jars

it explains why the ordering isn't there: `:api:assemble` doesn't depend on `:proto:assemble`, it depends on `:proto:classes` etc.

What should I do to ensure that all the jars are available when `findDuplicates` is run?

right now that is not the case because `:api:findDuplicates` is run before `:proto:assemble`

why does it care whether there are jars or directories in the classpath?

and if it's depending directly on a jar output from other task, that's bad

The `findDuplicates` task cares about the jar files because that is its source of information to examine whether there are duplicate file names

here is a code segment taken from the `findDuplicates` task:

```  @SuppressWarnings("LogAndThrow")
  private Set&lt;ArtifactFile&gt; readJarEntries(ResolvedArtifact artifact) {
    try (ZipFile zip = new ZipFile(artifact.getFile())) {
      return zip.stream()
          .filter(e -&gt; !e.isDirectory())
          .filter(e -&gt; !e.getName().startsWith("META-INF/"))
          .map(e -&gt; new ArtifactFile(e.getName(), artifact, e.getCrc()))
          .collect(Collectors.toSet());
    } catch (IOException e) {
      if (!artifact.getFile().exists()) {
        throw new GradleException(
            "The jar "
                + artifact.getFile().toString()
                + " doesn't exist.\n Run `./gradlew build` to generate all of the project's jars.",
            e);
      }
      throw new GradleException("Error while opening jar '" + artifact.getFile() + "'", e);
    }
  }```


who is calling `readJarEntries`, and with what values

```configuration.getResolvedConfiguration().getResolvedArtifacts().stream()
        .filter(a -&gt; !a.getFile().toString().endsWith(".exe"))
        .filter(a -&gt; !shouldIgnoreJar(a.getModuleVersion().toString()))```


this is a code segment from earlier in the task that creates the collection of `ResolvedArtifract`s

that should work unless you're not properly depending on those files

e.g.
```tasks.register("foo") {
    inputs.files(configurations.runtimeClasspath)
}```
will cause gradle to build those jars, because you're asking for them

do not depend on side-effects of assemble

currently `:api:findDuplicates` only depends on `:api:assemble`

then that's your problem, that isn't what actually provides the inputs you want

should I also add a dependency on `:proto:assemble`  then?

adding explicit task dependencies is usually the wrong answer, and always the wrong answer cross-project

oh i just re-read your message with the `inputs.files` code segment. now I understand this is your recommendation how to rewrite the task properly

ok now i need to figure out how to do that in java

`task.getInputs().files(project.getConfigurations().named("runtimeClasspath"));`

I think this will work, trying it out now

Based on the dry run, `api:assemble` is ran before `proto:assemble`

It works! Thank you <@U019L3NM4PK> :heart:

Javi, calling `assemble` (or `build`) at the root doesn't force any particular order of the `assemble` of subprojects, and there is no dependency between `api:assemble` and `proto:assemble` as I mentioned up at the start

looks like a feature request for DRY RUN to show the task that are going to run but if the order is not guarantied, show them in parallel or whatever

there's stuff like <https://github.com/dorongold/gradle-task-tree> but I don't think there's really a good way to render it for large task graphs

I.e. the version catalog is stored in artifactregistry. The com.google.cloud.artifactregistry.gradle-plugin is required to resolve that dependency.

Define the repository in `pluginManagement` block, then apply it in the `plugins` block.
Settings plugins are applied bfore the `dependencyResolutionManagement` block is executed. `dependencyResolutionManagement` is not special it is evaluated during normal settings script evaluation phase.

It is already defined and applied. I can for instance pull plugins from artifactregstry from within pluginManagement. It only fails in dependencyResolutionMangement.

(I.e. it fails with Not a supported repository protocol 'artifactregistry': valid protocols are [http, https, file, gcs, s3, sftp]) which seems to imply the plugin is indeed not applied properly. :man-shrugging:

From a quick look at the sources of that plugin, only repositories in `pluginManagement` are supported.

And they also have a feature request for it: <https://github.com/GoogleCloudPlatform/artifact-registry-maven-tools/issues/71>

Thank you for the info. I though I was just configuring it wrong somehow.

You can use rich versions in the version catalog file too, so you can use the `strictly` there either in the long form or as `!!` suffix: <https://docs.gradle.org/current/userguide/platforms.html#sub::toml-dependencies-format>

you could create your own platform that brings in both compose-bom and the upgraded material3 version

Yes using `version = { strictly = "1.1.0-alpha06" }` works perfectly fine! Couldn’t find a way to combine this with a `version.ref`, but not a big deal, it’s an exception anyway, won’t be doing this often. Thanks so much!

When you say “create own platform”, I am unfortunately not sure I understand what you mean. Something like making my own BOM locally, which brings in compose-bom + that specific version? Care to elaborate?

documented at <https://docs.gradle.org/current/userguide/java_platform_plugin.html>,
```// platform/build.gradle.kts
plugins {
    `java-platform`
}

javaPlatform {
    allowDependencies()
}

dependencies {
    api(platform(libs.androidx.compose.bom))
    constraints {
        api(libs.androidx.compose.material3)
    }
}```
then use `platform(projects.platform)` instead of `platform(libs.compose.bom)`

&gt; Couldn’t find a way to combine this with a `version.ref`
It's in the docs I linked you to.
The rich version declaration is in the `version` section and you just use that in the `version.ref` as usual.

Or you do as <@U019L3NM4PK> suggests :slightly_smiling_face:

Yup I hadn’t realized you can use this rich syntax in the [versions] block too. That was my bad, thank you again for pointing this out to me. I think I will go with this approach as the platform approach seems like a bit extra steps, and I want to remove this workaround as soon as possible anyway, when the artifact I am interested in goes to stable again.

The task looks like this

```fun Configuration.isDeprecated() = this is DeprecatableConfiguration &amp;&amp;
  resolutionAlternatives != null

fun ConfigurationContainer.resolveAll() = this
  .filter { it.isCanBeResolved &amp;&amp; !it.isDeprecated() }
  .forEach { it.resolve() }

tasks.register("downloadDependencies") {
  doLast {
    configurations.resolveAll()
    buildscript.configurations.resolveAll()
  }
}```

It fails like this:

```Execution failed for task ':downloadDependencies'.
&gt; Could not resolve all files for configuration ':testRuntimeOnlyDependenciesMetadata'.
   &gt; Could not find org.junit.platform:junit-platform-launcher:.
     Required by:
         project :```

the error message indicates that no version is specified for that artifact.

OK, but there never was; the `downloadDependencies` task worked fine in gradle 7.6, and I can do a `./gradlew test` quite happily in gradle 8, so whatever gradle needs to do to actually run the tests it can do.

Which suggests my notion of how to resolve all dependencies in the `downloadDependencies` task is now broken - but I'm not sure how, so I'm not sure how to fix it.

Did you also update Kotlin plugin?
Or maybe this is a build that uses embedded Kotlin plugin like when applying `kotlin-dsl` plugin?
Afair the `...DependenciesMetadata` tasks are added by the Kotlin plugin.

perhaps the scope of downloading is too broad - do you need dependencies from `testRuntimeOnlyDependenciesMetadata'`, for example?  If so that configuration will need the junit BOM or otherwise have an artifact version specified.

I've been on `kotlin("jvm") version "1.8.10"` for a couple of weeks

<https://youtrack.jetbrains.com/issue/KT-34394/Kotlin-JVM-runtimeOnlyDependenciesMetadata-implementationDependenciesMetadata-should-be-marked-with-isCanBeResolvedfalse|https://youtrack.jetbrains.com/issue/KT-34394/Kotlin-JVM-runtimeOnlyDependenciesMetadata[…]enciesMetadata-should-be-marked-with-isCanBeResolvedfalse> seems "related"

Ah, thanks. That looks like a sensible upstream bug.

But reading that, I wonder it worked before and did not also fail

What you could maybe do is to not resolve the configurations themselves, but instead create an artifact view, set it to lenient, and resolve that. Then it should not fail even if something cannot be resolved.

Thanks, that seemed to work:
```fun ConfigurationContainer.resolveAll() = this
  .filter { it.isCanBeResolved &amp;&amp; !it.isDeprecated() }
  .map { it.incoming.artifactView { isLenient = true } }
  .forEach { it.files.files }```

Hmm... not quite there. To explain, the goal is that a successful run of `downloadDependencies` should allow gradle to then work offline on that machine. I prove this by doing this:
```RUN ./gradlew downloadDependencies
RUN --network=none ./gradlew build```
in a Dockerfile

In the first project I tried the change above had the desired effect, but in a second project it didn't - the `RUN --network=none ./gradlew build` fails as so:

```* What went wrong:
Execution failed for task ':compileGroovy'.
&gt; Could not resolve all files for configuration ':detachedConfiguration3'.
   &gt; Could not resolve org.apache.groovy:groovy-astbuilder:4.0.9.
     Required by:
         project :
         project : &gt; org.apache.groovy:groovy:4.0.9 &gt; org.apache.groovy:groovy-bom:4.0.9
      &gt; Could not resolve org.apache.groovy:groovy-astbuilder:4.0.9.
         &gt; Could not get resource '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-astbuilder/4.0.9/groovy-astbuilder-4.0.9.pom>'.
            &gt; Could not GET '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-astbuilder/4.0.9/groovy-astbuilder-4.0.9.pom>'.
               &gt; <http://repo.maven.apache.org|repo.maven.apache.org>
   &gt; Could not resolve org.apache.groovy:groovy-dateutil:4.0.9.
     Required by:
         project :
         project : &gt; org.apache.groovy:groovy:4.0.9 &gt; org.apache.groovy:groovy-bom:4.0.9
      &gt; Could not resolve org.apache.groovy:groovy-dateutil:4.0.9.
         &gt; Could not get resource '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-dateutil/4.0.9/groovy-dateutil-4.0.9.pom>'.
            &gt; Could not GET '<https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-dateutil/4.0.9/groovy-dateutil-4.0.9.pom>'.
               &gt; <http://repo.maven.apache.org|repo.maven.apache.org>: Try again```


I really want to publish `downloadDependencies` as a plugin, but obviously it needs to be robust to multiple different gradle setups.

Ugh, I was wrong, reverting didn't change it at all. It seems that `Project.getConfigurations()` does not return `detachedConfiguration3`. Unclear yet whether it used to in Gradle 7.6, or if `detachedConfiguration3` is some new thing in Gradle 8.

And I'm wrong, it was broken in 7.6 too, I just wasn't enforcing the `--network=none` so it was hidden from me.

So where is `detachedConfiguration3` coming from...

there will be many detached configurations created/used by different plugins, for different purposes.  Does using the built-in Gradle cache (~/.gradle/caches/…) not work?  It has all the POM/module data, source/binary artifacts, etc.

You cannot write such a task.
You need to actually run each relevant task of such a build.

Detached configuration are not returned from `configurations` as they are detached. :slightly_smiling_face:

A plugin or task can use a detached configuration to use the Gradle resolve / download / cache mechanism to download files without polluting `configurations`.

There could also be other tasks that do not use detached configurations, but just plainly download things using any other means and that might then even not work offline when run repeatedly

There's no way to retrieve the detached configurations of all applied plugins?

Only by triggering the codepath that resolves those detached configurations

&gt; There could also be other tasks that do not use detached configurations, but just plainly download things using any other means and that might then even not work offline when run repeatedly
Yes, I accept there's no way of working around that.

Actually, there are plugins like the one you want to write and publish already.
They just suffer from the same problems you are hitting. :slightly_smiling_face:

I guess I've just got lucky until now in my plugins

I actually wonder, detached configurations are pretty common, so lucky you. :-D

Isn't `withPathSensitivity(NAME_ONLY)` what you are after?

Maybe? What I want Gradle to do is only take in to account the file names when fingerprinting the input. My understanding is that on its own `inputs.files(…)` will fingerprint contents (and presumably paths)… but doesn’t care about ordering of the files. The javadoc for `withPathSenstivity()` seems a little vague to me - it implies that `NAME_ONLY` still considers the file contents… but then what does `NONE` do?

`NONE` only considers the contents, completely ignoring the file path *and* name

I used it once for a task that is validating contents of files, where I don't care whether the file is renamed, because the content would still be valid or not

So when fingerprinting the inputs, you really want to only fingerprint the name of the file, but not the contents?

Then `inputs.files` is wrong, it will always fingerprint the contents which usually makes sense

If you really just want the filename because you do not even read the contents, use `inputs.property` and give it the file name(s)

so the answer to my question as stated is what you said… but the code was never doing what I wanted in the first place

integration test as in you're using Gradle TestKit?

that almost certainly is a classpath issue. `MyTask` and `MyTask_Decorated` (the latter of which gradle creates at build runtime with bytecode magic) are probably getting loaded into different classloaders and can't "see" each other

yeah my tests using gradle testkit do not have the error, but projects using my plugin sometimes do

oh, you said "I _can't_ seem to reproduce it in an integration test"

im currently trying to get a full stacktrace, but it only sometimes happens and  haven't had luck getting it to happen on my local yet, just ci server

```Caused by: java.lang.ClassCastException: Failed to cast object task ':aggregateLibraryMetadataFiles' of type com.grubhub.gradle.grublish.common.AggregateLibraryMetadataTask_Decorated to target type com.grubhub.gradle.grublish.common.AggregateLibraryMetadataTask
        at org.gradle.internal.Cast.cast(Cast.java:41)
        at org.gradle.internal.Transformers$CastingTransformer.transform(Transformers.java:63)
        at com.grubhub.gradle.grublish.common.AggregateLibraryMetadataTask$Companion.apply(AggregateLibraryMetadataTask.kt:67)
        at com.grubhub.garcon.buildplugin.grublish.impl.GrublishLibPlugin.apply(GrublishLibPlugin.kt:44)
        at com.grubhub.garcon.buildplugin.grublish.impl.GrublishLibPlugin.apply(GrublishLibPlugin.kt:15)```
here is my real stacktrace

this is a custom task type defined in kotlin

the call to cast is coming from my custom `maybeCreate` function as seen here: <https://gradle-community.slack.com/archives/CAD95CR62/p1676424003705409>

but that code came from the real one with just the extra tweak of adding the configuration closure

kind of. it happens, but not 100% of the time

unless when it doesnt happen, the project is not resolving to my new version of the plugin.... that might be possible since we use dynamic versions sometimes

I would normally suggest dropping a breakpoint and verifying my idea that you have multiple classloaders in play

ah, i dont have int test repro yet, just local in a downstream consumer project of my plugin

use the prod code, no need for a test for this purpose

but the classloader thing is interesting. i guess i need to learn more about how gradle manages classloaders

ah ok, i guess i need to learn how to hook a debugger up to a build then

well if you had a break point in that function, you could just inspect `Thing::class.java.classLoader` and dig into it

`-Dorg.gradle.debug=true` + IDEA and `Remote JVM Debug` run configuration

and you can add your plugin to the project as an included build so it's built from source

I think im hitting <https://github.com/gradle/gradle/issues/23148>

when i tried to repro with a buildSrc plugin, it didnt repro

This works

```buildscript {
    dependencies {
        classpath("com.android.tools.build:gradle:7.4.0-beta02")
    }
    configurations.configureEach {
        resolutionStrategy {
            force("com.android.tools.build:gradle:7.4.0-beta02")
        }
    }
}```

Maybe use strict version constraint?
```buildscript {
    dependencies {
        classpath("com.android.tools.build:gradle:7.4.0-beta02!!")
    }
}```

If noone comes up with an idea, maybe providing an <https://stackoverflow.com/help/mcve|MCVE> could help. At least I did not fully get the situation from your description. :slightly_smiling_face:

<@URQ797WRW> so, here is example, what I want to achieve. I solved my needs through BuildService, but I am not sure that it is optimal solution. <https://github.com/HlebMaliborski/JetpackInstrumentation/blob/build-service/buildSrc/src/main/kotlin/plugin/InstrumentationPlugin.kt>

You should not use the internal registry there, but instead do as documented on the build serivces documentation page.

Other than that, I cannot tell how to properly do in Android build, as I don't do Android development.

That's what I run:
```./gradlew buildHealth cyclonedxBom```
This leads to the following error (with gradle 8, just a warning with gradle 7)
```- Gradle detected a problem with the following location: '&lt;path-to-root-project&gt;\build\reports\dependency-analysis\build-health-report.txt'.
    
    Reason: Task ':buildHealth' uses this output of task ':cyclonedxBom' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':cyclonedxBom' as an input of ':buildHealth'.
      2. Declare an explicit dependency on ':cyclonedxBom' from ':buildHealth' using Task#dependsOn.
      3. Declare an explicit dependency on ':cyclonedxBom' from ':buildHealth' using Task#mustRunAfter.
    
    Please refer to <https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency> for more details about this problem.```
When I run the tasks separately everything works fine.

First I thought the reason for that was, that the CycloneDx plugin has a `destination` property which is marked as `@OutputDirectory` (see <https://github.com/CycloneDX/cyclonedx-gradle-plugin/blob/master/src/main/java/org/cyclonedx/gradle/CycloneDxTask.java#L231|here> ) and is by default at `${buildDir}/reports`.
And when I configure the `cyclonedxBom` as follows, the error is gone:
```tasks.named("cyclonedxBom") {
    destination = file("${buildDir}/reports/cyclonedx")
}```
Want I find strange is, that when running the `cyclonedxBom` task together with the `testAggregateTestReport` of the <https://docs.gradle.org/current/userguide/test_report_aggregation_plugin.html|Test Report Aggregation Plugin>, which uses `${buildDir}/reports/tests` as output directory, I don't have the same issue. So I'm not sure if it is maybe the Dependency Analysis Plugin declaring its inputs in a strange way.
Has anybody an idea who "is at fault" here?

What's strange is that Gradle says that `build\reports\dependency-analysis\build-health-report.txt` is an output of `cyclonedxBom`, and input of `buildHealth` (from the name, looks more like an output of the latter).

Yeah it's definitely an output of `buildHealth`

And gradle probably thinks that it is an output of `cyclonedxBom`, because this task declares  `build/reports` as an output directory and this applies recursively, meaning every file in all sub directories is an output file of this task.

But I agree, that it is strange why apparently gradle thinks it is an input of `buildHealth` (and therefore my question if it is maybe a weird configuration issue in the dependency analysis plugin)

Ah, apparently, `buildHealth` in root project takes as input the outputs of `generateBuildHealth` task which includes this `build-health-report.txt`, and yes CycloneDX declaring `build/reports` as an output directory is wrong. So the culprit is CycloneDX here, it should either put everything in a subdirectory it "owns", or somehow declare a list of output files (it can still have an outputDirectory property to compute those output files, but as `@Internal` then)

Ahh okay, didn't find that, thanks for confirming!
I will open an issue on the CycloneDX Plugin

Yeah, that's the new standard layout `gradle init` generates, to make it easy to add further projects to the build in the future if you need to, like an `api` project or a separate `docs` project or whatever.

If you don't like that, just change it. Move the stuff from `lib` or `app` or whatever up to the root directory and delete the `include` from the settings script if you prefer that layout.

Or create a `basic` project with `init`, then you end up with just an empty root project and then you can continue from there.

My recommendation would be to not generate into the source tree, but into the `layout.buildDirectory`, then the `clean` task already deletes the files without a need for the specific clean task.

That indeed seems sensible, but sadly I'm configuring a task for a third-party plugin which doesn't let me decide where the files are generated. I'm adding `inputs` and `outputs` to get caching

I see.
You could configure the `clean` task to delete that directory, or you can add that dependency, it's probably both ok in that situation.

Error is
```Type mismatch: inferred type is T? but T was expected```

<https://github.com/gradle/gradle/issues/12388>

In a build script or in a plugin? It’s fine in Intellij in build.gradle.kts but not in a plugin class.

both, works fine for me in a includeBuild plugin

ah yes, Kotlin intentionally changed behavior <https://youtrack.jetbrains.com/issue/KT-48623/Type-nullability-enhancement-improvements> and `kotlin-dsl` uses the flag to disable it

I don’t follow, does that mean this is a bug in kotlin? Is the Transformer api correctly typed, and using k2 is an ok workaround, or should I expect this to break in the future under k2 as well?

there is a package-level `@NonNullApi` in Gradle: <https://github.com/gradle/gradle/blob/master/subprojects/core-api/src/main/java/org/gradle/api/package-info.java>
thus the Transform API is not actually correct

oh actually that should have been moved around as of Gradle 8, so I think it's correct now (?)

I’ll write up an issue with a reproducer to at least get it logged.

Issue created here <https://github.com/gradle/gradle/issues/23935>

most likely classloader issues resulting in `MyExtension` class loaded multiple times

Or the existing `myExt` extension has a different type.

But you should anyway not do such cross-project configuration.

i ended up solving it by making the root project find the files via fileTree + filter instead of actually adding the files to the list

i was just hoping to have it be more explicit with the inputs

(this was related to my other issue i posted about earlier)

If one project needs outputs from other projects you should neither configure that project from the other projects to have them, nor reference the files from those other projects in the one needing them.
You should use proper cross-project publication instead: <https://docs.gradle.org/current/userguide/cross_project_publications.html>

interesting. in my case, it is not any kind of jar or java artifact. I am just trying to aggregate some data generated by each subproject build. is there a recommended way to do this?

What kind of files it is doesn't matter.
That applies to any files.
That way is the recommended way.
For example the `test-report-aggregation` plugin uses that technique to collect the test results from the other projects.
And the `jacoco-report-aggregation` plugin uses that technique to collect the JaCoCo results and the sources from the other projects.

Hi guys. I want to create a simple task which runs a bunch of our linters in sequence and fails (exiting early) if a task in the sequence fails.
I had this, but some tasks are failing and the end result still says SUCCESS if the last task succeeds:
```afterEvaluate {
    task healthCheck(dependsOn: ['test', 'ktlintFormat', 'detekt', 'lint', 'connectedMockDebugAndroidTest']) {
        tasks.findByName('ktlintFormat').mustRunAfter 'test'
        tasks.findByName('detekt').mustRunAfter 'ktlintFormat'
        tasks.findByName('lint').mustRunAfter 'detekt'
        tasks.findByName('connectedMockDebugAndroidTest').mustRunAfter 'lint'
    }
}```