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

Gradle Community

```// gradle/libs.versions.toml
[libraries]
group-name = "group:name:version"

// build.gradle
dependencies {
    configurationName(libs.group.name) {
        artifact {
            type = "extension"
        }
    }
}```
I believe you mean "extension" rather than "classifier", because that's what "@" does

Thanks a lot.

I really mean classifier, for example:
```testImplementation("org.apache.kafka:kafka-clients:3.0.0:test")```

Unfortunately this doesn't seem to work.

TOML:
```[versions]
kafka = "2.8.1"

[libraries]
kafka-clients = { module = "org.apache.kafka:kafka-clients", version.ref = "kafka" }```
`build.gradle`
```    api(libs.kafka.clients) {
      artifact {
        classifier = "test"
      }
    }```
Error message with Gradle 7.4.1:
```* What went wrong:
A problem occurred evaluating project ':my-project'.
&gt; Could not resolve all dependencies for configuration ':my-project:runtimeClasspath'.
   &gt; Could not find method artifact() for arguments [build_3bwyqt3y3wr3wnc2ldw9wgwci$_run_closure2$_closure3$_closure6$_closure7@675386e7] on constraint org.apache.kafka:kafka-clients:2.8.1, attributes=null of type org.gradle.api.internal.artifacts.dependencies.DefaultDependencyConstraint.```


Ah, wait. I think I misunderstood how to use this in a Java platform (or rather _not_ use it in a Java platform).

Note that _ideally_ you wouldn't have to explicitly use classifiers and/or extensions from dependency declarations. Dependency selection should be based on variants, according to variant attributes, and you can use component metadata rules to declare variants on dependencies that lack them.
<https://docs.gradle.org/current/userguide/component_metadata_rules.html#making_variants_published_as_classified_jars_explicit>
<https://docs.gradle.org/current/userguide/java_testing.html#publishing_test_fixtures>

Do something similar to what gradle itself does to manage tasks when fulfiling `implementation(project("subproject"))` dependencies

I don't actually know how it does it, but browse through their code to figure out.

that would be by exposing configurations from `ParentImage` to be consumed in `ChildImage`

<https://docs.gradle.org/current/userguide/cross_project_publications.html>

definitely recommended to do so instead of depending directly on tasks across projects

For most things, Gradle shares outputs through variants: <https://docs.gradle.org/current/userguide/cross_project_publications.html>
Here, this would mean exposing the both the version and the image as variants, and then consume those from the tasks, such that `calc-version` only depends on the `version` variant, which will trigger the `calc-version` task of the depended-on project.
I'm not sure how well it fits with your needs though.

i'm pretty sure this is exactly what i need

for example, I migrated `buildSrc/` to `buildSource/` + `includeBuild("buildSource")` and would have to replace all my:

```plugins {
    `java-library-convention`
}```
to:

```plugins {
    id("java-library-convention")
}```
Is there a way to use an `includeBuild("buildSource")` but still get the generated plugin accessors?

```plugins {
    `java-gradle-plugin`
}```
will build and register all `*.gradle.kts` as precompiled script plugins

<https://docs.gradle.org/current/userguide/java_gradle_plugin.html#java_gradle_plugin>

oh wait you're asking about the plugin accessors in the root build? hmm

yeah. buildSrc automatically generates those for the root build, but `includeBuild("buildSource")` does not last time I tried it

I've never had that since I use dot-qualified names so ``backticks`` don't work anyway, but I was under the impression that it was supposed to work…

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

I guess it's expected that it doesn't currently work

Yes, sadly.
One of the few drawbacks when switching from `buildSrc` to included build right now

Are you saying that "clean" brings the env. vars back?

or stopping and restarting the daemon brings the env. vars back?

Might also depend on how your code is reading those env vars?

Stopping the daemons via `./gradlew --stop` and then re-running `clean build` of which will start up a new daemon per the output message.

For example:
```❯ ./gradlew --stop
Stopping Daemon(s)
1 Daemon stopped
❯ ./gradlew clean build -x test
Starting a Gradle Daemon, 4 stopped Daemons could not be reused, use --status for details```

It looks like the PID changes at some point so my best guess is that something without access to my env is spawning a new process?

Really hard to say from the information you provided.

Gradle spawns several new processes potentially.
Test worker processes to run tests,
worker processes for worker api work items with process isolation,
Kotlin compile daemon,
Gradle daemon,
...
But none should "loose" access to environment variables.


Btw. the trained behaviour to always also run `clean` is usually caused by Maven behaving bad, mixing outputs and having stale files and so on.
With Gradle you should usually not always run `clean` with your build, as all that you cause with it is making some of the most useful features like up-to-date checks void.
With Gradle if you really need to call `clean` to get a good build result, that is usually more a sign of some bug in the build scripts or plugins of the current project.

For the record, my best working theory on the root of the issue I was encountering was JDK 11, older version of Gradle, and the mac M1 chip not playing nicely together.

Once I upgraded gradle to 7.4.1 and resolved some plugin changes, things seem to be working without issue. :thumbsup:

IMO 1 is definitely the way to go if you are publishing anything; it's just less confusing if the `my.group:foo-api` and `my.group:foo-impl` come from `foo-api` and `foo-impl` projects

no, I would not do 3. I find it easier when every project is a leaf in the tree structure and you don't have to think about projects being parents of other projects. it also creates issues such as <https://github.com/gradle/gradle/issues/4823>

hm, why the leaf comment? I have a big build of 4 apps + shared code, and nesting is I think a big help

```:rootSharedModule1
	:contract
	:impl
:rootSharedModule2
	:contract
	:impl
...
100modules..
...
app1
	:app1SharedModule1
		:contract
		:impl
	...
	20 modules

:app2
	:app2SharedModule1
		:contract
		:impl
	...
	20 modules
...```

so you’d rather have `:app1-sharedModule1-contract` ? i.e. 200 modules flat in root?

anyways, my point mostly being .. why even tell consumers this is only a api? should they care? .. granted when there are still modules which are not split .. leading to confusion I think

I agree that 3 is a bad idea for purely practical reasons. source-containing modules should not be parents of other modules. I speak from experience, as I manage a build with 4000 modules.

we use combination of 1 and 2 like this:
```:foo
    :foo-api
    :foo-impl```
so in settings it is like:
```include(":foo:foo-api", ":foo:foo-impl")```
this has a little drawback of creating project foo in gradle.
if you don't need the project you can put projects foo-api and foo-impl in foo folder in git but include only subprojects in settings.gradle like this:
```include(":foo-api", ":foo-impl")
project(":foo-api").projectDir = file("foo/foo-api")
project(":foo-impl").projectDir = file("foo/foo-impl")```

<@UES7RHBDZ> what if foo has some ui related stuff that can be shared, would you then nest is like this ?

```:foo
	:contract
	:impl
	:ui```
or
```:foo
	:contract
	:impl
:foo-ui```

I’m not super happy with either, we established that folders mean nesting, not dashes .. yet it doesnt really fit insode the foo, as its not on the same level .. possible if I were to stick some subfolder there like

```:foo
	:data
		:contract
		:impl
	:ui```
but I’d hate to deal with git conflicts if this ‘data’ folder insert were to happen

You are right that by default the exploded war is not built, because that would be an unnecessary step and make things slower if a war should actually be built. But you can easily add a task that does it *without* the need to first build and then extract it like this in Kotlin DSL
```val explodedWar by tasks.registering(Sync::class) {
    with(war)
    into(layout.buildDirectory.dir("exploded-war"))
}
```
(There could be syntax errors, written on mobile)

there are different things and I think you're referring to the build script classpath, not specifically the build cache.

if you update a _version_ or _dependency coordinates_ in the toml file, the generated accessors will be identical, so the classpath is going to be the same

however, depending on the tasks, some might be out of date, so _not cached_, simply because you upgraded a dependency that is used as an input

if you change an alias name, or add an entry, then the classpath is invalidated and it would behave more or less like a buildsrc change.

Thanks for comprehensive answer!

Yes, I'm referring to the build script classpath.
Adding or removing new entry is the only problem I have with custom solution I've came up with.

All build cache is lost on every change in buildSrc, because build script classpath was changed. Essentially causing a clean build.

I had a hope, that Version Catalog somehow deals with this problem.

P.S. By "build cache" I mean not Gradle Build Cache, maybe it's called project cache (/build).

Remote application being a an application that is running?  When you start the application, you would need to attach the jacoco agent to the process to get coverage.

I’m starting the application with jacocoagent running in tcpserver mode, but I’m not sure how to pull the coverage data after test run is done

I found some 7 year old thread on the forums related to it, where someone solved it with an Ant-task but I’m not sure if that is still possible.. would go something like this:
```tasks.register("dumpCoverage") {

// groovy version:
//        ant {
//            taskdef(name: 'dump',
//            classname: 'org.jacoco.ant.DumpTask',
//            classpath: configurations.jacocoAnt.asPath)
//
//            dump(address: '<http://server.com|server.com>',
//            destfile: "$buildDir/jacoco.exec")
//        }

    ant {
        task(
            mapOf(
                "classname" to "org.jacoco.ant.DumpTask",
                "classpath" to configurations.jacocoAnt.get().asPath
            ),
            "dump"
        )
    }
}

tasks.test { finalizedBy(tasks.withName("dumpCoverage").single()) }```


Why are you running in TCP server mode? Do you have something that is connecting to the agent?

CI pipeline starts application as a docker with jacocoagent in server mode and a parallel separate step runs tests using gradle against this docker container

Now I want the gradle task that runs the tests to also connect and dump the coverage data before being done

Independent from "triggering the dump", if you run in TCP server mode, some capable tool has to connect to that server to retrieve the data. Where should it dump to otherwise?

yes.. and jacoco ant plugin has pre-defined task for this, as does jacoco maven plugin.. was wondering if there’s any conventional way of doing it with gradle  as well :slightly_smiling_face:

Ah, sorry, forgot that the ant task actually retrieves the data and writes it to a file.
I thought it only sends the dump command.
Well, Ant is still a first-class citizen in Gradle, so you can just use the Ant task.

If you don't like that, you can also copy a few lines of code from <http://www.eclemma.org/jacoco/trunk/doc/examples/java/ExecutionDataClient.java> to just do it in an own class.

I'm not aware of any Gradle built-in functionality besides the Ant task, but I might be wrong of course.

I believe that’s because you are not really _setting_ an artifact but instead changing the `type` of those found by default.
What happens if you replace `artifacts.each` with `artifact` to actually _define_ the artifact you want.

Tried that first… seems to have the same effect

Ugh, then it is not intended. Can you file an issue please?

This is how Gradle parses the string notation: <https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/notations/DependencyStringNotationConverter.java|https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src[…]e/api/internal/notations/DependencyStringNotationConverter.java>
and it delegates type and classifier to <https://github.com/gradle/gradle/blob/dc9faf1ca64fc86506dd9b8f5461b05b468241cb/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/dsl/dependencies/ModuleFactoryHelper.java#L23|https://github.com/gradle/gradle/blob/dc9faf1ca64fc86506dd9b8f5461b05b468241cb/sub[…]pi/internal/artifacts/dsl/dependencies/ModuleFactoryHelper.java>
There you can see that it explicitly set `transitive = false` when a type is provided, so I assume you'd have to do the same in your code.

Sorry, brain got in the way… I obviously meant ‘extension’ here in the Groovy code. Will try to get this right in the actual issue.

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

<@UDC9Q9RD0> Thanks for looking in the code, that means assumptions on my side were wrong. And of course changing that is going to be interesting.
Thanks <@UBA11MM6Y> for the issue.

I think you can write:
```"binaryImplementation"(projects.lib) { targetConfiguration = "releaseAar" }```
(though of course you should preferably use variants when possible: <https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing>)

Looks like! I have the same issue. Cloudflare says the host is down.

<https://discuss.gradle.org/t/received-status-code-524-from-server-origin-time-out/42526>

Reminder to *always* reconfigure your builds to go to `mavenCentral()` before `gradlePluginPortal()` so you're not impacted by JCenter (or Gradle's JCenter _mirror_) flaky availability. The only downside is that you'll also reach to Central for the artifacts actually hosted on the Gradle Plugin Portal, that's a small price to pay for a more stable build environment.
(also, JCenter still rewrites some POM files from time to time, breaking Gradle verification metadata)
<https://github.com/gradle/gradle/issues/15406>
```repositories {
    mavenCentral()
    gradlePluginPortal()
}```


<@UDC9Q9RD0> where exactly should we put this:
```repositories {
    mavenCentral()
    gradlePluginPortal()
}```
Does it go inside the `buildscript` block? or inside `pluginManagement` block?

`pluginManagement`, you should practically never use `buildscript`

And if you use `buildSrc` or an included build for convention plugins, *also* put it in that project's settings in *both* `pluginManagement` and `dependencyResolutionManagement` .

i publish all my plugins to both ... but i believe not all plugins are published to central, only gradle (it is a lot easier than publishing to central)

Plugins themselves are not the problem, their dependencies are. Plugins are hosted directly by the Gradle Plugin Portal, and that's OK. Their dependencies aren't, and the Gradle Plugin Portal will then redirect to JCenter (or Gradle's JCenter mirror). Putting Central first ensures that those will be downloaded from Central rather than JCenter. For plugins that aren't on Central (most of them), Central will return a 404 and Gradle will fallback to the Gradle Plugin Portal, and you should never actually use JCenter.

Correct me if I'm wrong, but didn't Jcenter shutdown on 2/1/2022? Shouldn't the redirect have been removed by this point?

JCenter is kept readonly "indefinitely" (that is, except when it's down). It cannot easily be put aside as some dependencies are only available in JCenter and not in, say, Central; so changing the behavior of the Gradle Plugin Portal would mean possibly breaking oldish projects whose plugins depend on libs that are only available on JCenter (or possibly plugins themselves only available on JCenter, and neither on the Gradle Plugin Portal nor Central)

And to make things even more interesting: There could be a file with the version string in a sub-project which should be used over the "general" version file, so the hierarchy would be:

Generic version file &lt; Project-specific version file &lt; Environment variable &lt; Gradle property.

You would express that in a `Provider` chain, starting at the most important one and then do a `Provider.orElse` chain.

Thanks, Louis! I thought along those lines, too.

How would that work with `RegularFileProperty` and checking that the files (don't) exist?

I think something like this wouldn't work, would it?
```def myVersion = project.objects.fileProperty().fileValue(project.file("specific"))
  .orElse(project.objects.fileProperty().fileValue(project.file("global")))
  .map(file -&gt; "read version string from file")
  .orElse("default")```

I did not try the code, but it should work.

However, you have to begin with the Gradle property, since it wins when present, then go down in priority order, finishing with the files and possibly a default convention.

It's all working as advertised, thanks! :slightly_smiling_face:
```ext {
    def env = providers.environmentVariable("MY_VERSION")
    def specificFile = providers.fileContents(layout.projectDirectory.file("specific")).asText
    def globalFile = providers.fileContents(layout.projectDirectory.file("global")).asText

    myVersion = env.orElse(specificFile.orElse(globalFile)).getOrElse("default")
}

tasks.register('printVersion') {
    it.doLast {
        project.println(myVersion)
    }
}```
Example:
```# MY_VERSION=env ./gradlew -q printVersion
env
# ./gradlew -q printVersion
specific
# rm specific &amp;&amp; ./gradlew -q printVersion
global
# rm global &amp;&amp; ./gradlew -q printVersion
default```

I see there is this plugin:
<https://github.com/springdoc/springdoc-openapi-gradle-plugin>

Also note, that it seems like a README on how to apply this plugin is wrong, check  <https://github.com/springdoc/springdoc-openapi-gradle-plugin/issues/74|springdoc-openapi-gradle-plugin/issues/74>.

This is usually an edge eviction bug in Gradle's dependency graph resolver. Often reordering dependencies, adjusting excludes, etc. can avoid it

I got similar bug only when synchronizing project in idea when I has activated dependency locking. At the same time a build from terminal was successful.
It seems idea mucks with dependencies while synchronizing leading to some data race.
IIRC, locking was active for some configurations and issue disappeared after changing locking config.

Yes! i have same behavior. Gradle build work but synchronizing project in idea was failed

Can you tell how you disabled the locking in idea?

I didn't. Issue was transient and after some changes (dependency versions, number of configurations to lock) idea started to synchronize again

If you manage a reproducer, please open an issue.
You could also try a 7.5 nightly as a couple fixes are already available.

No, in my project we use private repository. But i can create scan. I found one strange dependency, when i remove it project successful import. If i now this dependency, can i get more information about graph resolver error?
```implementation(group = "ru.tinkoff.tdk", name = "spring-boot-starter-tdk")```

I've lost state where it was reproducible but if I manage to get it again I'll try to file an issue

I'm basically trying to implement the behavior achieved by `com.gradle.scan.plugin.BuildScanExtension#background` but don't see a good execution API that works for this context, leading me to believe that I'd have to fall back on manual `Thread` construction (or equiv via `Executors`)

`Executors` and `CompletableFuture` could be best bet if you don't want to bring any dependencies. If you are ready for more heavy things - take what you're more comfortable with. But kotlin things would be painful if you're targeting more than one gradle major version.

Also if you what to run some native process I could recommend `zt-exec` instead of java's `ProcessBuilder`, it's much less painful.

yeah, I'm hoping for a Gradle API since Gradle already manages worker/thread pools, etc.  I _can_ do a bare Exeuctor/Thread execution but would prefer something integrated if such an API exists...

can you just use a FileCollection?
```files(
    rootProject.layout.projectDirectory.dir("path/to/${project.name}"),
    rootProject.layout.projectDirectory.dir("path/to/default")
).find(dir -&gt; dir.isDirectory())```

Seems to work and is more readable, thanks! :slightly_smiling_face:

Thinking about it, I don't even need a `FileCollection` in this case and a list would have the same effect:
```[
    rootProject.layout.projectDirectory.dir("path/to/${project.name}"),
    rootProject.layout.projectDirectory.dir("path/to/default")
].find(dir -&gt; dir.isDirectory())```

Ah, scrap that. `files()` does way more and is preferable. :+1:

I think you're missing the repo:
`url = uri("https://&lt;redacted&gt;/artifactory/my-awesome-repo")`

It's there, sorry I removed it for clarity. The URL for the POM checks.

Do you see the pom in the gradle cache? After clearing out that directory?

Or maybe try another approach: see if it works if you manually set the URL of a public repo. If that works, something is off in your repo

Yeah, so it downloads the POM from the right location but it doesn't place the POM in gradle cache.

I could try your trick with another repo just to chek, but that plugin is not on maven central

If it's a plugin, then there might be some gradle support files involved, could those be missing?

Wel I would have thought that the first directory I mentioned are the support files you are talking of

<https://plugins.gradle.org/m2/com/github/node-gradle/node/com.github.node-gradle.node.gradle.plugin/3.2.1/>

Unless there is anything else I need, but I don't think so, as DEBUG log doesn't show Gradle trying any other URLs

We also only have the pom, jar, and sources.jar, so that should work

And how do you apply the plugin? Could be the issue I think

We use the "traditional" method, though I cannot rule out that there might be instances where we use a plugins block

<@U035X1F32FQ> yeah, so I switched to the traditional method and it works now!!

Great! Then you're probably only missing the "extra" files for gradle plugins that translate from plugin id to maven coordinates

I do not see anything obvious that you missed.
If the legacy application method works, then everything under `com/github/node-gradle/gradle-node-plugin/3.2.1/` is OK and what is problematic is the part under `com/github/node-gradle/node/com.github.node-gradle.node.gradle.plugin/3.2.1/`
I would double check that you copied the right thing and preserved its name.

does the Kotlin version make it clearer that the initial `configurations { instrumentedJars { ... } }` _creates_ a configuration?

ok that does clarify things a bit, but i'm still confused

would a project include the code provided in all the examples? or just example 1 plus one of 2, 3 or 4

I would have hoped the docs were clear enough that you need 1 to 5.

this part confused me:


``` If it's not the case, you will need to explicitly declare how the artifact is generated.

Example 3. Explicitly declaring the task dependency of an artifact```
it seems like you do example 2 sometimes but example 3 `if it's not the case...`

but if you're saying all examples are needed together, i think that helps, let me chew on it

Right. It basically tells you that if the artifact you build is _not_ from an `AbstractArchiveTask` then you need 3, otherwise not.

so basically if you use a `Jar` task you can skip 3

yes, yo can mix them as you want (one per project/module)

I do it big bang style lately but just because I'm very confident, first times I was more cautious

yo can do things before even moving to kts, like:
replace single quotes by doubles
make sure all the plugins are applied in plugins blocks

(I had a longer list of steps but I forgot)

&gt; • replace single quotes by doubles
&gt; • make sure all the plugins are applied in plugins blocks
Already done that. Phew! :wink:

the idea is to make the commit with the change...mostly a name change

ah.. adding parenthesis to dependencies implementation/api...

then when you do the change...it may seem just like a file renaming (it won't be that nice, there is always something)

Alright, thanks for the explanation and the insight, Christian! :slightly_smiling_face:

i'm trying to do this:
```        val depAction = Action&lt;Any&gt;  {
          println("helloworld")
        }

        for (subproject in project.subprojects()) {
          subproject.getPlugins().withId("com.hyperscience.gradle.docker.DockerImage", depAction)
        }```
and the error i'm seeing looks like this:
```None of the following functions can be called with the arguments supplied:
public abstract fun subprojects(p0: Closure&lt;(raw) Any!&gt;): Unit defined in org.gradle.api.Project
public abstract fun subprojects(p0: Action&lt;in Project!&gt;): Unit defined in org.gradle.api.Project```

just do `withId("...") { println("hello") }`

i think i'm actually very far off here
i should have,
```for (p in project.subprojects) {
...
}```
but `subprojects` is unexpectedly empty for all my projects

i have this declared in one of my projects,
```dependencies {
    dockerBuild(project(path=compiled_packages, configuration="dockerBuild"))
}```

it's slowly dawning on my that i have no idea what i'm doing :smile:

i have a plugin that sets up explicit task dependencies and i want to get away from that, and use proper cross project publications

this is the part i want to replace: <https://gist.github.com/stevesta/836ee7d21f05d0799c87fec127f37174#file-dockerimageplugin-kt-L71-L81>

i try to set up the configurations here:
<https://gist.github.com/stevesta/836ee7d21f05d0799c87fec127f37174#file-dockerimageplugin-kt-L50-L53>

To begin with, read the JavaDoc of `getPlugins()` and learn that you instead should use `getPluginManager()` :wink:

Also, is `com.hyperscience.gradle.docker.DockerImage` really a plugin id, that you use in `plugins { ... }` block? Looks more like a FQCN of a task.

thanks
yes, it really is a plugin id. did i organize it in the wrong spot?

Why do you actually want to do that?
Just publish each of the jars individually and any build tool will pull them in automatically.

(btw. the `doNotCacheIf` is useless, as `Jar` tasks are not cacheable anyway)

I ended up publishing individually. I just thought it was convenient for the user to only have to depend on a single dependency

you can publish a single "all" module which will transitively include all the rest; your users only need to include that one.

Just make a new project that depends on the other projects and has no jar

```-Dhttps.socketTimeout=900000 -Dhttps.connectionTimeout=900000 -Dhttp.socketTimeout=900000 -Dhttp.connectionT
imeout=900000```
as i see, they are useless

Yeah, those properties are Apache HttpClient properties, they don't help for the wrapper download

If a read timeout of 10s isn't enough, you're going to have a really bad time with large downloads in general. You could download manually and copy it into `GRADLE_USER_HOME` yourself, some details here <https://gradle-community.slack.com/archives/CAHSN3LDN/p1643769067289629>. But if you're also downloading dependencies too, I think you need some kind of caching proxy

Oh, you are using another location:
```Downloading <https://registry.tcsbank.ru/repository/gradle-distributions/gradle-7.3.3-bin.zip>
...........10%.......
Could not unzip C:\Users\t.p.maerov\.gradle\wrapper\dists\gradle-7.3.3-bin\3i0k0kngugxu3f39187g8j4dr\gradle-7.3.3-bin.zip to C:\Users\t.p.maerov\.gradle\wrapper\di
sts\gradle-7.3.3-bin\3i0k0kngugxu3f39187g8j4dr.
Reason: zip END header not found
Exception in thread "main" java.util.zip.ZipException: zip END header not found```
I don't think you're seeing a timeout. I think that host is truncating the binary

Afair you can juse specify the exact version and Gradle handles it appropriately. Did you made a different observation?

Actually I remember it was broken at some point.
What Gradle version are you using?

There was for example
<https://github.com/gradle/gradle/issues/9462>
and
<https://github.com/gradle/gradle/issues/11639>

Yeah i’ve checked it in the past, and for some reasons the version hasn’t been found. But probably some issue with the `snapshotsOnly()` notation in the repositories clojure?

```repositories {
    maven {
        credentials {
            username = artifactoryUser
            password = artifactoryPassword
        }
        url = URI("$artifactoryUrl/libs-snapshot-local")
        mavenContent {
            snapshotsOnly()
        }
    }
}```

Maybe, try to do it without that and see if it works.
If so, that's a bug in the repository content selector I'd say.

I could recommend to look at immutable snapshots approach (like nebula.release plugin) with gradle dynamic versions if you can control snapshot publication side

<@UJUMPU407>, i’m basically using a similiar plugin (<https://github.com/datalbry/gradle-plugin-semver>) but unfortunately, the Artifactory of my customer does only allow snapshots as dynamic versions / pre releases and final versions might only contain digits + dots. So no suffix / prefix / affix

I didn't think artifact transformations (TransformAction&lt;T&gt;) were incremental in the first place. do you mean cacheable? (I don't know any way to turn that off)

I meant incremental like this (<https://docs.gradle.org/current/userguide/artifact_transforms.html#implementing_incremental_artifact_transforms|https://docs.gradle.org/current/userguide/artifact_transforms.html#implementing_incremental_artifact_transforms>)

I bumped into <https://issuetracker.google.com/issues/223365583>

oh so they can be incremental, interesting. I never ran into that before (only wrote single-file-to-file transforms)

Hmm.. What do you mean by rolled back? What is F2FS?

F2FS: the kind of filesystem, not EXT4, nor BTRFS, see <https://wikipedia.org/wiki/F2FS>

rolled back: the java process sees the directory as cleared, but it's not and the files are still there when gradle exits.

What happens if you run the build with `--no-watch-fs`? Same behavior?

Only `--no-daemon` makes it work as expected.

Basically my task populates a directory after clearing it. The populating works, but not the clearing, and I end up with old and new files in the directory.

That is very strange. And on `ext4` this works?

So something in F2FS breaks the virtual-fs of gradle, should I report that somewhere ?

Since `--no-watch-fs` doesn’t work either, that doesn’t seem to be related to the virtual file system in Gradle. Does `--info` or `--debug` show some interesting things?

My fs is listed:
`2022-04-04T18:32:51.720+0200 [DEBUG] [org.gradle.internal.watch.vfs.impl.DefaultWatchableFileSystemDetector] Detected f2fs: /home from /dev/nvme0n1p4 (remote: false)`

Ah, maybe something interesting:
`2022-04-04T18:32:50.668+0200 [DEBUG] [org.gradle.internal.vfs.impl.AbstractVirtualFileSystem] Invalidating VFS paths: [/home/java/javafx-sample/build/native]`

I don’t see why `--no-daemon` would make a difference.

Maybe you have terminal or gradle daemon holding some file open in offending path. Linux really deletes stuff only when file is closed and process is dead

You can try `lsof` to find if it's the case

lsof shows the gradle daemon having the files in the directory opened, that's all.

Linux does physically deletes the file when no more process access it, but the files should not be listed anyway in `ls` if it was the reason, I believe.

`--info` prints:
```Not watching /home/java/javafx-sample since the file system is not supported
Watching the file system is configured to be enabled if available
File system watching is active```

If that may help: the directory is marked as `@OutputDirectory`, if I replace the annotation with `@Internal`, it works

oops, sorry, forget this, it doesn't work either.

Raah... now it fails on ext4 too. The only situation where it works for sure is with `--no-daemon`

All happen as if the daemon vfs didn't record the deletion and the files pop back when it syncs with the concrete fs

Sorry, I misled you. The problem seems finally related to the fact that the files in the directory are native libraries, loaded from the build script, in specific class loaders, but when using the daemon the class loaders linger in the daemon (before being GC one day) and the native libraries stay loaded.

When running with `--no-daemon` the libs are unloaded when the JVM dies.
Not sure how to solve this though.

The source path in the output is configurable using the `sourceFolder` config option which is by default set to `src/main/kotlin` for the `kotlin` generator. My guess is that if you have to add `src/commonMain/kotlin`, that this is actually configured that way, except if the documented default value is wrong.

I also don't like the generated sources to be an own Gradle build, but incorporate it in the existing build, so I also suppress almost all other generated files like the Gradle project files and configure the `sourceFolder` to be empty and thus directly the output directory.

This is how I do it, though it is using the Java generator, as I don't like the result of the Kotlin generator for its overuse of static state / companion object state, which is has pretty negative side-effects in my case:

```val openApiGeneratorIgnoreFile = layout.projectDirectory.file(".openapi-generator-ignore")

openApiGenerate {
    generatorName.set("java")
    outputDir.set(layout.buildDirectory.dir("generated/sources/openapi/main/java").map {
        it.asFile.absolutePath
    })
    inputSpec.set(downloadNexusOpenApiSpec.map {
        it.outputs.files.singleFile.absolutePath
    })
    generateApiDocumentation.set(false)
    generateApiTests.set(false)
    generateModelDocumentation.set(false)
    generateModelTests.set(false)
    invokerPackage.set("org.sonatype.nexus.client")
    apiPackage.set("org.sonatype.nexus.client.api")
    modelPackage.set("org.sonatype.nexus.client.model")
    configOptions.set(mapOf(
        "sourceFolder" to "",
        "dateLibrary" to "java8"
    ))
    ignoreFileOverride.set(
        openApiGeneratorIgnoreFile.asFile.absolutePath
    )
}

// work-around for <https://github.com/OpenAPITools/openapi-generator/issues/10214>
tasks.openApiGenerate {
    inputs
        .files(openApiGeneratorIgnoreFile)
        .withPathSensitivity(NONE)
        .withPropertyName("openApiGeneratorIgnoreFile")
}

pluginManager.withPlugin("idea") {
    configure&lt;IdeaModel&gt; {
        module {
            generatedSourceDirs.addAll(tasks.openApiGenerate.get().outputs.files)
        }
    }
}

sourceSets {
    main {
        java {
            srcDir(tasks.openApiGenerate)
        }
    }
}```

oh does it really create a whole gradle build? i never noticed that.

in my config it does not create a gralde project, just the src dir:
``` % ls build/openapi/generated
src```

Maybe you have an `.openapi-generator-ignore` file already?
Or maybe you use a version where the result is different.
:man-shrugging:
But the remaining points stay valid.

yeah, thanks a lot. I set sourceFolder and now it works perfectly

`~/.gradle/caches/jars-9` are some build logic instrumented jars while `/.gradle/caches/modules-2` are dependencies. I doubt there is any documentation for jars-9.

hm. Can you elaborate on the "instrumented" part?

For example for configuration cache Gradle has to detect the `System.getProperty()`  in the build logic. So there are some transformations on the build logic so that is possible and result jars are cached in these folders.

One other thing to note is that, in this particular case, `theTask` is a lifecycle task and is actually supposed to be invoked by user (be it a human or CI server), but I am actually looking for general recommendations.

I would think that you always *register* the task, but in a `doFirst{}` you can check if the conditions to actually execute the task are fulfilled. If not, throw an exception to fail the build before the task is executed.

there's also `enabled = false` (eagerly configured) and `onlyIf { false }` (lazily evaluated) to ensure that the task is not executed

I would also always register the task, and use one of those to limit when it will run if needed

Turns out it was user error: the project had multiple modules, and the test filter came back with no tests in one of those modules.

check out <https://github.com/junit-team/junit5/|junit>, a gradle maintainer (<@UABSS056X>) is contributing there. :slightly_smiling_face:

Which still doesn't mean it is fully idiomatic. :smile:

But <https://github.com/jjohannes/idiomatic-gradle/> should probably be a good reference even with <@U023HSZL88M> not being a Gradle employee anymore. :slightly_smiling_face:

Micronaut is close to that. There's still some use of `allprojects`/`subprojects` for edge cases (aggregation) which are not yet greatly supported by Gradle.

See for example: <https://github.com/micronaut-projects/micronaut-aot/>
One module which uses convention plugins, as well as shared plugins (for other Micronaut projects)

Gradle itself: <https://github.com/gradle/gradle>

Spring Boot (with the convention plugins written in Java):
<https://github.com/spring-projects/spring-boot/tree/main/buildSrc>

Ah you checked Spring Boot… I would say it is pretty idiomatic last time I checked.
Only that it does not use the Gradle DSLs for the convention plugins, which is maybe the thing that makes it not a good candidate for your case (?)

Thanks for the suggestions! I'm not totally sure what you mean by _idiomatic_. Can I substitute _best practice_ instead? :thinking_face:

FYI Spring Boot uses _allprojects_ <https://github.com/spring-projects/spring-boot/blob/main/build.gradle|here> and junit5 does similar.

_micronaut-aot_ could be a good candidate, but I'm unsure why it's not using _buildSrc_.

&gt;  Gradle itself
Nice!