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

Gradle Community

Specifically, I have two libraries that I must force, in their entirety, into the final link:
```        linkerArgs.add "-Wl,-force_load,$buildDir/libvw_jni.a"
        linkerArgs.add "-Wl,-force_load,$buildDir/libboost_program_options.a"```
I am currently downloading the two a second time into $buildDir.  Would prefer to use them from the local cache.

Open to alternate syntax / methodology for "force_load" equivalent.

"force_load" is macOs example.  Here is linux:
```        linkerArgs.add "-Wl,--whole-archive"
        linkerArgs.add "-L${buildDir}"
        linkerArgs.add "-lvw_jni"
        linkerArgs.add "-lboost_program_options"```


If you are ok with 90% match (figure made up, but definitely below 100)

The files could be missing completely, or they could also be in a subproject, or the root project directory might be configured to be somewhere else by the setting script, ...

If you require Gradle 7.0 at least, you could check for `settings.gradle` or `settings.gradle.kts` as with 7.0 they are mandatory. But even then you just verify that you are in the settings directory, not necessarily the root project directory.

But 100% certainty you probably just get by querying the project using the tooling api.

are you using it on a cli script or on a Gradle task?

If it were inside Gradle he would probably just use `rootDir` :smile:

yeah, is it mandatory to use CLI instead of a Gradle task?

Let me dig into more details of my scenario:
I am writing a library that will be verifying structure of the Kotlin project. This lib will be running as JUnit test (obviously written in Kotlin), accessing and verifying Kotlin code base inside this test.

The main problem here is to get the Gradle project root dir from JUnit Test (kind of CLI as it is outside Gradle, but truly it is a Java Program).

Inside test I can run
```File("").absoluteFile.path ```
to get the "current" directory path.  This provides path to a source set eg. `.../project/module/src/test` (thus the traversing up approach)

After <@U01DUV4Q882> "CLI question" I am thinking that It may be better to traverse up and try to run Grade command and parse `rootDir` from command output :thinking_face:  (which command would you recommend?)

BTW1 I need to explore similar approach for Maven, but this is another story

BTW2 I will provide option to manually set root dir, but it would be super convenient for devs to have a method that can simply get all of the kotlin files from the current project (Gradle project root dir)

As you are in JVM, probably better follow what I said.
Use the tooling API to get information about the build.

Also, I found what Gradle was missing <https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/dsl/LazyPublishArtifact.java|https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src[…]/org/gradle/api/internal/artifacts/dsl/LazyPublishArtifact.java>

I suppose you don't use the same version of Gradle as your colleagues.
If you can, use the gradle wrapper to make sure everyone's using the same version. Maybe it's actually already in place on the project: use `./gradlew bootRun` instead of `gradle bootRun`.

(fwiw, that would be an incompatibility between a plugin trying to create a LazyPublishArtifact with the old API, and a newer version of Gradle where the API has changed)

Well, something within your `android { ... }` closure in `android\build.gradle' line: 24` is messed up. With Groovy DSL you do not get a better error message and need to either see the error or try with commenting out which part is invalid.

That's one of the reasons I recommend using the Kotlin DSL. You immediately get type-safe build scripts, better error messages if you mess up the syntax and amazingly better IDE support if you use a proper IDE like IntelliJ or Android Studio.

You can get some of this info from ps-aux but not for why gradle needed a new daemon....e.g., the jvmargs and path look the same:
```% ps aux | grep gradle
keny             29909 155.6 27.2 433860912 18241968   ??  Rs   10:40AM  15:16.78 /Users/keny/.sdkman/candidates/java/current/bin/java -XX:MaxPermSize=3g -XX:MaxMetaspaceSize=8g -XX:+UseParallelGC --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx20g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /Users/keny/.gradle/wrapper/dists/gradle-8.0.2-all/25ipb77ce0ypy3f9xdton1ae6/gradle-8.0.2/lib/gradle-launcher-8.0.2.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.0.2
keny             30408   0.0  0.0 408636112   1472 s000  S+   10:50AM   0:00.00 grep gradle
keny             30074   0.0  1.2 433323552 775984   ??  Ss   10:44AM   0:20.40 /Users/keny/.sdkman/candidates/java/current/bin/java -XX:MaxPermSize=3g -XX:MaxMetaspaceSize=8g -XX:+UseParallelGC --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx20g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /Users/keny/.gradle/wrapper/dists/gradle-8.0.2-all/25ipb77ce0ypy3f9xdton1ae6/gradle-8.0.2/lib/gradle-launcher-8.0.2.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.0.2```

<https://gradle-community.slack.com/archives/CAHSN3LDN/p1680294995492509?thread_ts=1680293507.519299&amp;cid=CAHSN3LDN|https://gradle-community.slack.com/archives/CAHSN3LDN/p1680294995492509?thread_ts=1680293507.519299&amp;cid=CAHSN3LDN>

This has nothing to do with gradle, just that your lombok version is incompatible with jdk you're using to build. Spring Boot BOM will bring some version of lombok that you might have to upgrade if you're using newer jdk than that boot version targeted.

Execution failed for task ‘:compileJava’. java.lang.IllegalAccessError: class lombok.javac.apt.LomokProcessor (in unnamed module @0x363a5ab7) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sum.tools.javac.processing to unnamed module @0x363a5ab7

Untitled

We use this code which works for us (just replace functional tests with integration tests): <https://github.com/oss-review-toolkit/ort/blob/0bee05120ac5ad5acede533e1193c0caa786a5d2/build.gradle.kts#L219-L240>

&gt; our integration tests sometimes skips running
Do you know why? Is this perhaps caused by Gradle noticing the inputs haven’t changed, so it skips the tests?

(IntelliJ used to force the all tests to re-run, even if they hadn’t changed, but the latest version of IntelliJ will skip unchanged tests but it doesn’t display it in an intuitive manner)

Tests are run on Github actions with gradle caching, it simply said
&gt; &gt; Task :app:integrationTest FROM-CACHE
The inputs probably _weren't_ changed, since `integrationTest` doesn't depend on `main` but I would like to tell gradle that such dependency exists

<@U01N075J77D> I don't really see you doing anything to make functional tests depend on main

```    // Associate the "funTest" compilation with the "main" compilation to be able to access "internal" objects from
    // functional tests.
    kotlin.target.compilations.apply {
        getByName("funTest").associateWith(getByName(KotlinCompilation.MAIN_COMPILATION_NAME))
    }```
I don't want to do this, since my integration tests should _not_ be able to access _anything_ from the main sources

do you still get Task :app:integrationTest FROM-CACHE even when a file in src/main changes?

This was the build for a commit where `src/main` changed, yes :slightly_smiling_face:

how do the tests in src/integrationTest work? They don’t access files in src/main directly, but do the main sources get published to a Maven repo? Or do they get packaged into a Docker container?

packaged to docker

The integration tests use REST / JMS to blackbox-test the application, and integration-tests depend on a `dockerBuildImage` task which packages the application into a container image

are they packaged to Docker via a Gradle task?

Yeah, I'm using `com.bmuschko.docker-spring-boot-application version 9.3.1`  , which must've falsely thought the docker image was up to date..

okay cool, that’s good. This is where it might get tricky though. The first step is to tell Gradle that the integration test task depends on the `dockerBuildImage` task.

I had that, and the docker image was built as part of the build :thinking_face:

where it might get tricky is if the `dockerBuildImage` task is correctly wired up, so Gradle can fingerprint the inputs/outputs and skip the task if necessary

yeah so I guess the inputs/outputs aren’t registered properly

```      @Suppress("UNUSED_VARIABLE") // Gradle determines name of test suite by the name of the variable
      val integrationTest by registering(JvmTestSuite::class) {
         testType.set(TestSuiteType.INTEGRATION_TEST)

         useJUnitJupiter()

         dependencies {
         }

         targets {
            all {
               testTask.configure {
                  dependsOn(tasks.dockerBuildImage)
                  shouldRunAfter(test)
               }
            }
         }
      }```


Damn, okay.. :disappointed: so I guess that's an issue that needs to be filed in the plugin.. is there anything I can do on my end to _always_ assume that input is updated then?

You probably need a dependency on the project as shown here: <https://blog.gradle.org/introducing-test-suites#test-suites---a-better-way-forward>

in the GitHub action that showed

&gt; Task :app:integrationTest FROM-CACHE
what was the result of the dockerBuildImage task? Was it also FROM-CACHE, or something else?

Also see <https://blog.gradle.org/stop-rerunning-tests>

```&gt; Task :app:dockerBuildImage
Building image using context '/actions-runner/_work/my-service/my-service/app/build/docker'.
Using images 'my-service'.

&gt; Task :app:compileTestKotlin

&gt; Task :app:dockerBuildImage
Step 1/8 : FROM openjdk:17-slim
 ---&gt; 37cb44321d04
Step 2/8 : LABEL maintainer=root
 ---&gt; Running in 2ac9bae4fc41
Removing intermediate container 2ac9bae4fc41
 ---&gt; 4053d7984046
Step 3/8 : WORKDIR /app
 ---&gt; Running in 7824e4d9d78b
Removing intermediate container 7824e4d9d78b
 ---&gt; 66775799fb5c
Step 4/8 : COPY libs libs/
 ---&gt; 4ccb83a13379
Step 5/8 : COPY resources resources/
 ---&gt; 07594ab8e36a
Step 6/8 : COPY classes classes/
 ---&gt; da4d15a0b2cc
Step 7/8 : ENTRYPOINT ["java", "-XX:+UseContainerSupport", "-cp", "/app/resources:/app/classes:/app/libs/*", "com.company.my.app.MyApplicationKt"]
 ---&gt; Running in 6686bad67dc7
Removing intermediate container 6686bad67dc7
 ---&gt; 23f0960863ea
Step 8/8 : EXPOSE 8080
 ---&gt; Running in 3e91ee0851f6
Removing intermediate container 3e91ee0851f6
 ---&gt; df1ac9790427
Successfully built df1ac9790427
Successfully tagged my-service:latest
Created image with ID 'df1ac9790427'.```


Hmm, it’s strange that it ran :thinking_face: . If it ran, then because the integration test task has this `dependsOn(tasks.dockerBuildImage)` then the intergration test task should also run

Oh wait, Build Cache is enabled so if `dockerBuildImage` doesn’t have an output file then Gradle does its magic

Since a while, Gradle also supports the per-task `--rerun` option, maybe just use that explicitly.

there are two options I can think of

1. add an output file to `dockerBuildImage` that contains the hash of the built docker image. If it has an output, then Gradle Build Cache will be able to kick in.

   You can use a `doLast {}` block for this. It has to be an output file, because that’s the only type of Gradle task output considered by Build Cache.
2. compute and add the Docker image hash as an input to the integrationTest task, so Gradle will re-run the task if the image hash changes. Something like

```val integrationTest by registering(JvmTestSuite::class) {
targets.all {
  testTask.configure {
      val imageName = "my-image"
      inputs.property("dockerImageHash",
          providers.exec {
              executable("docker")
              args(parseSpaceSeparatedArgs("inspect --format='{{index .RepoDigests 0}}' $imageName"))
          }.standardOutput.asText)
  }
}
}```
(Docker command from <https://stackoverflow.com/q/32046334/4161471>)

Thanks a lot guys, was stuck in meetings so need some time to catch up with the articles etc, but really appreciate the help :star-struck:

I ended up adding inputs to the test task:
```
         targets {
            all {
               testTask.configure {
                  dependsOn(tasks.dockerBuildImage)
                  shouldRunAfter(test)
                  inputs.files(fileTree("src/main")) // &lt;-- Here
               }
            }
         }```
The docker image hash you suggested <@U02KX5B7EVC> exited with exit code 64 for some reason, even though the command Gradle was trying to use worked when I invoke it directly. Perhaps permission issues..
Either way, I think the above solution has the added benefit that it only runs the integrationTests if the main sources change, even if the docker image is rebuilt. It's good in my case, cause something is off with the caching of the docker image task so it always runs, which would make my tests always run as well..

Having the `dependsOn` is not enough to have the docker image tasks output as input for up-to-date cache. **Instead of** using `dependsOn` you would do `inputs.files(tasks.dockerBuildImage)`. That way the  outputfile of the task is considered when the fingerprint of the test task is calculated and you get the task dependency automatically.

The `dockerBuildImage` task also has the id of the built image in a file as output file, also for it's own up-to-dateness, so actually just using that should already have worked.

Besides your problem that the docker image task is not up-to-date.

Nice, that should be even better.. It also seems that the task is not up-to-date because no docker image digest is generated.. not sure what to do about it yet but it should be solvable :slightly_smiling_face:

So `dependsOn` only generate temporal dependency, without adding dependencies on the actual outputs from the task?

Yes, and thus practically any `dependsOn` is a code-smell (except with a lifecycle task on the left-hand side)

You should always prefer wiring inputs to outputs and get implicit task dependencies

&gt; exited with exit code 64 for some reason
possibly `docker` is on your user path, but not the system path? :thinking_face: But I’m just guessing.

What I’ve done before for building Docker images is to do it manually.

I set up a separate `./docker/` dir that contains the Dockerfile and docker-compose.yml (that’s only used for building the image)

Then I define a Gradle Sync task `prepareDockerBuild` to sync requisite files into `./docker/build/`, so that it’s clear about what files are used for the building the Docker image.

And then a `dockerBuild` exec task that runs `docker-compose build`, with working dir set to `./docker/`.

If the `prepareDockerBuild` task doesn’t sync any files, then Gradle will skip `dockerBuild` task - which is faster than invoking Docker and waiting for Docker to figure out that  nothing has changed.

do you have reproducible archives set up <@U037XSGBXT8>?<https://docs.gradle.org/current/userguide/working_with_files.html#sec:reproducible_archives>

it’s a “why isn’t this enabled by default??” option

hehe :smile: yeah.. legacy reasons I suppose, like so many other things in Gradle..

Like why so many APIs are not lazy by default..

indeed. Hopefully in 9.0 it’s better… <https://github.com/gradle/build-tool-roadmap/issues/28>

Your solution sounds nice btw, but I'm in an org where I think I'm one of the persons with most Gradle knowledge, and I wouldn't know how to do that without spending a couple of days exploring I suppose.. I think there's a general resistance to having "code in gradle", rathern than just using Gradle to "declare builds", so it'd be a bit controversial to add more complex logic such as that for sure

mm yeah, for sure. I find it tough because a lot of the Gradle plugins just don’t follow the Gradle API well enough. Ideally they should just drop-in, and work… but when they don’t, they can be a real pain. But maybe your is fixed when you use `inputs.files(tasks.dockerBuildImage)` as suggested by <@URQ797WRW> and with reproducible archives :crossed_fingers:

Yeah I got everything on my end working after those changes :slightly_smiling_face: Had to adjust it to `inputs.files(tasks.dockerBuildImage.get().imageIdFile)` , and then do a small change for the dockerBuildImage task to cache properly (by adding explicit tag, was using :latest implicitly)

Think I'll try to summarize today's Gradle adventure into a blogpost.. can be useful to share within my client's org at least.. :slightly_smiling_face:

it’s best to use `map {}` instead of `.get()` though - so the task isn’t configured unless it’s required

```inputs.files(tasks.dockerBuildImage.map { it.imageIdFile})```

Why do you explicitly dereference the image id file property?
This way you probably loose the implicit task dependency.
And it should work with what I wrote I think.

Or well, you don't loose the task dependency, as it is an output property, so will work.
But it should be unnecessary as it is the only output property.

Gradle complained about this:
```
- Task `:app:integrationTest` of type `org.gradle.api.tasks.testing.Test`: cannot serialize object of type 'com.bmuschko.gradle.docker.tasks.image.DockerBuildImage', a subtype of 'org.gradle.api.Task', as these are not supported with the configuration cache.
  See <https://docs.gradle.org/7.6.1/userguide/configuration_cache.html#config_cache:requirements:task_access>```

&gt;&gt; it’s a “why isn’t this enabled by default??” option
&gt; hehe :smile: yeah.. legacy reasons I suppose, like so many other things in Gradle..
I'd say probably more what makes more sense. :smile:
Many people would majorly complain if they loose their timestamps in the archive.
And even without that option, the archive will be up-to-date if the inputs and outputs didn't change.

&gt; Gradle complained about this:
Ah, okay, was not aware about that CC problem

I'm also getting this when I try to upgrade to Gradle 8:
```Configuration cache entry discarded due to serialization error.
Configuration cache state could not be cached: field `commandProvider` of `com.bmuschko.gradle.docker.tasks.image.Dockerfile$EntryPointInstruction` bean found in field `instructions` of task `:app:dockerCreateDockerfile` of type `com.bmuschko.gradle.docker.tasks.image.Dockerfile`: error writing value of type 'org.gradle.api.internal.provider.DefaultProvider'```


Does it mean the plugin needs updating? :smile:

Maybe, I don't know.
Didn't use it with a Gradle 8 build so far

What license is the <https://plugins.gradle.org/docs/publish-plugin|Publish Plugin> released under?

The JAR contains an Apache 2.0 license, but there’s no license information in the POM or sources JAR <https://plugins.gradle.org/m2/com/gradle/publish/plugin-publish-plugin/1.2.0/>

build.gradle

Kotlin 1.3 is quite old, and some of the config in your build.gradle is also old. How did you make this build.gradle? Are you trying to adapt an existing project?

It might be a good idea to start afresh. Make sure you have the latest version of Gradle installed (8.1.1) and In a new directory run `gradle init`. It will run through some steps to create a new project.

Actually, for Furhat robot (virtual or real), we create skills coded in Kotlin. In virtual environment, I've created a template skill called "OpenAISkill to interact to chatgpt. The build.gradle was automatically generated. So, I think I need to readapt it with recent versions.

I would expect they become compatible with KMP some day

Yeah I hope so too. :slightly_smiling_face:

I guess there is too much wiring they do maybe.
But feel free to open a feature request if there is none yet, you will get my thumbs-up :slightly_smiling_face:

Reading and writing took more effort than was available during the day today, but I'll follow up and get back here..

So I finally got around to submitting an issue.. :sweat_smile: <https://github.com/gradle/gradle/issues/25107>

While rethinking about it, test suites most probably are platform agnostic. It is just the case that there is only a `jvm-test-suites` plugin registering the `JvmTestSuite` type. But there could probably easily plugins be written that support other types as the test suites container is polymorphic.

Hmm, right.. So Kotest could for instance create a KotestMultiplatformTestSuite.. :thinking_face:

In a test with testkit I am getting this crash, is it enough changing the jvm size via org.gradle.jvmargs in the test project gradle.properties?

```# There is insufficient memory for the Java Runtime Environment to continue.```

How can I exclude a project dependency? Is it possible?
```configurations.configureEach {
    exclude(
        // how do I exclude a project dependency here?
        project(":my-lib")
    )
}```
Docs only mention excluding an external module dependency <https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:excluding-transitive-deps>

I'm not sure I did this right. Like this? <https://scans.gradle.com/s/l2teadb75l4ja>

I have `implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:_")` in `buildSrc/build.grade.kts` which I understand influences the `kotlin-dsl` version. But changing its version still causes errors

There’s no need to adjust the Gradle-embedded Kotlin version - use `kotlin-dsl` as is.
The issue is due to a back-version of the kotlin-dsl plugin expecting Kotlin 1.5 but upgraded to Kotlin 1.8.10 (as expected, to align with embedded Kotlin).

btw, this: `implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:_")` is not `kotlin-dsl,` which is a Gradle-provided plugin (not Jetbrains).  that kotlin-gradle-plugin is from kotlin(“jvm”) in a build script.
Related to that, build scripts should never mix kotlin(“jvm”) (which is for your application code) with `kotlin-dsl` (which is for your build script code).

Looking at this plugin view it’s likely there’s a build script that has both `kotlin-dsl` and `kotlin("jvm")`, resulting in conflicting Kotlin versions.  As noted above, never do that - any given script (or custom plugin) is either building Gradle code (`kotlin-dsl`) or your application code (`kotlin("jvm")`)

I don't think I define both `kotlin-dsl` and `kotlin("jvm")` in the same gradle file... My `buildSrc/build.gradle.kts` looks like this:
```plugins {
    `kotlin-dsl`
}

repositories {
    google()
    mavenCentral()
    mavenLocal()
}

dependencies {
    implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:_")
    implementation("com.android.tools.build:gradle:_")
    implementation("custom plugin already working")
    implementation("new plugin which breaks the build")
}```
I've been using refreshVersions for version management. I tried removing `<http://plugin.org|plugin.org>.gradle.kotlin.kotlin-dsl=2.1.7`, but it also does not help

this shouldn’t be present for buildSrc projects: `   implementation(“org.jetbrains.kotlin:kotlin-gradle-plugin:_“)`

It is the KGP version that is applied by the convention plugin

well, it can be, if you intend for your plugin to apply kotlin(jvm), but it may need to be on the compileOnly configuration.

&gt; This version of Gradle expects version '4.0.7' of the `kotlin-dsl` plugin but version '2.1.7' has been applied to project ':buildSrc'. Let Gradle control the version of `kotlin-dsl` by removing any explicit `kotlin-dsl` version constraints from your build logic.	

But I tried removing `implementation(“org.jetbrains.kotlin:kotlin-gradle-plugin:_“)` and it's still not working

that’s not what the message says.  somewhere in the plugin code it’s applying the plugin.

I also tried to force kotlin-dsl version to 4.0.7 and it wasn't working

Just don't use a version but the accessor

And provide a build scan with the correct version applied

We cannot guess what the error changes to ;-)

Well, I'm off for the weekend, thank you for trying to help me

<@U02S31Y7J2K> Sorry moving thread here since i realized i posted in the wrong channel :upside_down_face:

&gt; The closest you can get is to provide some object representing the version on doing your computation (lazily, once) in toString().
Could you expand on this? Essentially have a POJO that contains all the info and do the computation in `toString()`?

Thank you, I'll play around with that :saluting_face:

<@U01AFL38GBF> we are using custom plugin which used internally nebula plugin to calculate version based on tags, available release branches and branch where you are.
we are calling it like:
```tasks.register('projectVersion') {
	doLast {
		println "${project.version}"
	}
}```
to get project version we can call:
```./gradlew projectVersion```

At one point I was using such a thing to compute the version from a `git describe`: <https://github.com/tbroyer/gradle-incap-helper/blob/21afe339d6281ee040db5547cbded7ff21b59ae8/build-logic/src/main/kotlin/VersionFromGit.kt>

<@UDC9Q9RD0> thats very close to what I ended up with!

One thing I'm a little confused about is why I'm overriding `toString` instead of just exposing the computed value? I can't seem to find anything around the advantages in my googling :thinking_face:

using `toString` allows you to defer the computation until the first use of the version.

if you have a JVM project then I think the only standard option for coverage is JaCoCo’s requirements <https://docs.gradle.org/current/userguide/jacoco_plugin.html#sec:jacoco_report_violation_rules>

If you wanted to make a custom plugin then there’s the possibility of <https://docs.gradle.org/current/userguide/build_services.html#operation_listener|listening to build events>, and I think you should be able to get access to the <https://docs.gradle.org/current/javadoc/org/gradle/tooling/events/test/package-summary.html|test completion results>. I think this API is intended to be used by IDEs, so they can show passed/failed tests, but it should be suitable for writing a simple plugin too.

Cool, thanks, I'll look into <https://docs.gradle.org/current/javadoc/org/gradle/tooling/events/test/package-summary.html|test completion results>

I'd guess you are still on 1.x which is JUnit 4 based.
So if you do not use JUnit platform, the default JUnit 4 is used and the Spock specs are run.
If you do use JUnit platform, of course the JUnit 4 test are not run anymore.

I would recommend updating to Spock 2.3, as Spock 2.x is now also a JUnit platform engine.

Alternativiely, if for whatever reason you cannot udpate, you could add the JUnit Vintage engine, so that the JUnit 4 based tests like Spock 1.x tests are run on JUnit platform

As long as I don't run in too many backwards incompatible issues, upgrading makes sense. New tests are being written in kotlin, and not certain migrating the rest will be worthwhile. Thanks!

Oh, well, update and throw away kotest :smile:

But yeah, then just add the vintage engine and it should be good

remove all other modules from being `include`d in `settings.gradle`?

configure-on-demand can skip configuring unrelated projects, but I'm not sure if it allows skipping compiling their build scripts or not

I think the long-term goal is for project isolation to make it safe to configure only a subset of projects

but for now, configure-on-demand and kotlin dsl don't play well together

<https://docs.gradle.org/current/userguide/migrating_from_groovy_to_kotlin_dsl.html#before_you_start_migrating>
&gt; Enabling the incubating configuration on demand feature is not recommended as it can lead to very hard-to-diagnose problems.

buildscript block is rarely needed.  Define the plugins by id in the plugins block.

where you have subprojects you can define the plugins directly, or create <https://docs.gradle.org/current/samples/sample_convention_plugins.html|convention plugins> to do that (and other cross-cutting configuration).

Gotcha thanks. And the next question would be if I have a plugin for a subproject which I want to define with a version stored in properties file, is it idiomatic to define the plugin under the root settings pluginManagement block with apply false and then define it in the subproject. Am I correct?

current convention is to define the plugin coordinates/version in version catalog (typically libs.version.toml) and reference that as needed.

But can I reference that within a subproject? From my understanding according the doc I can reference the version only within the pluginManagement

you can reference version catalog in subprojects.  Not sure where `pluginManagement` keeps coming from - it isn’t referenced in version catalog <https://docs.gradle.org/current/userguide/platforms.html|documentation>.

<https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_management|https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_management>

that’s settings/init scripts, a different (older) approach from version catalogs for defining versions.  Follow the guidance for version catalogs to setup plugin versions.

Thanks. I will check the new way to set up versions 


How can I understand what is the new and old way? Does the documentation informs which way is the newer one? 

they are both valid ways but serve different purposes.  For most projects - use the version catalog.  For advanced / special cases pluginManagement can be used.

Right. In my case I'm using for spinnaker plug-ins 

Btw. `apply false` within `pluginManagement { plugins { ... } }` is pointless.
That block does anyway not apply anything anywhere.
It only defines default versions for plugins if they are applied somewhere else in the build without version.
It is the old pre-version-catalogs way to centralize the version declaration for plugins.

am I right that when `libs.versions.toml` is present under `gradle`, is it not needed
```dependencyResolutionManagement```
defined in the `settings.gradle.kts`?

partially.  the `versionCatalogs` underneath there is typically not used when you have the toml file, though you could use it to have different catalogs, either defined in code or from different toml files.

you may still need `dependencyResolutionManagement` for other things, such as defining repositories.

crossposted here since it is an android question too <https://gradle-community.slack.com/archives/CJYS1DAP5/p1682960651843109>

They are not generated in the same directory, not more than all tasks have their output in the same `build` directory. Each of the publications has its own output directory. I'd expect the tasks to run in parallel with CC.

if I’m using <https://docs.gradle.org/current/userguide/publishing_maven.html#ex-declaring-repositories-to-publish-to|a file-based repo> then they’ll all end up in the same directory some how, I’m pretty sure it’s the `PublishToMavenRepository` tasks that are doing that

```publishing {
  repositories {
    maven(file("build/custom-maven-repo")) {
      name = "LocalDir"
    }
  }
}```

Again, each task has its dedicated directory underneath. Just like all tasks have their output in `build`

sorry, I don’t understand what you mean. I only see one directory…

ooh you mean nested within the `build/custom-maven-repo` directory

but what happens if the publications have outputs that might overlap? (Which Gradle will print warnings about). Will Gradle detect this and decide the tasks won’t run in parallel?

&gt; ooh you mean nested within the `build/custom-maven-repo` directory
Exactly, the output directories for the actual tasks are `build/custom-maven-repo/foo/foo.gradle.plugin`, `build/custom-maven-repo/foo/bar.gradle.plugin`, and `build/custom-maven-repo/com/example/mycode/`.

&gt; but what happens if the publications have outputs that might overlap? (Which Gradle will print warnings about). Will Gradle detect this and decide the tasks won’t run in parallel?
I don't know, but I also don't know what you mean.
How could there be an overlap?
Every artifact has its own publish task.
Only problem I could imagine is if you have different artifacts with the same coordinates, but that would mean your build simply is misconfigured.

&gt; How could there be an overlap?
yeah, through misconfiguration

Well, then just fix the misconfiguration. :smile:
I'm not sure how it would behave, just try it and see. :slightly_smiling_face:

yeah for sure, I can fix bad config like that, but I was using that as an example. I was curious if Gradle determined parallelism based on task output.

Afaik if CC is in use, all tasks are run in parallel, unless one depends on the other

If the configured toolchain is compatible with the JVM used to run Gradle, then compilation can happen in-process, and you can debug your annotation processor when attaching to the Gradle process.
But as soon as you configure a toolchain that's *not* compatible, then Gradle will have to launch a separate daemon for compilation using the specified toolchain.

To debug your compilation, I'd suggest either:
• using a `javax.tool.JavaCompiler` (possibly through compile-testing) in a test, and then debug the test process: <https://docs.gradle.org/current/userguide/java_testing.html#sec:debugging_java_tests>
• run Gradle with `--debug`, find the "Compiler arguments" line in the output, then run the equivalent `javac` command (with Gradle out of the equation), passing the `-agent` argument as an additional `-J` argument (`javac -J-agent:…`), and transforming other JVM arguments to prefix them with `-J` the same way (you could also of course pass an `-agent` argument to the Gradle compilation task's `jvmArgs` and force Gradle to fork a compiler daemon)

Ah, I might just leave it unset then. A little more consistency in the build environment is nice-to-have, but not necessary here.

hi :wave:

It’s hard to guess what’s wrong from just the error message. Can you share more info? Like the `gradle.build` and `settings.gradle` files, the commands you’re running, what version of Gradle you’re using. What do you think the problem is? When did it start? Are you able to change the error at all, by commenting out config?

And most important, please share the full error literally

Currently, the issue is that I am using `project` inside of it for various cases, and it seems like the error message tells me that I can not use that at all.

At first, I was using project.file it to get a hold of some temporary file to download something into, which it gets deleted at the end of this task. For this, a replacement seems to be `public File getTemporaryDir()` which exists inside `DefaultTask` so using that it seems like it’s all okay now

But then, we’re also using the `project` object in order to both: 1) Get access to the copy action in order to take that downloaded zip and paste it into a provided directory. 2) Get the `zipTree` function which helps us deal with that downloaded zip file to pass into the `from` function of that copy task.

For the copy task, maybe the Worker API is what I am looking for, as I see a nice example there of getting FileSystemOperations injected into it, so that we can get the `copy` function and use it using this worked, so I will look into that.

But I couldn’t find some documentation about the zipTree fuction, and trying to also inject `FileOperations` seems to fail, it only knows how to inject `FileSystemOperators`, with error “Unable to determine constructor argument #2: missing parameter of type FileOperations, or no service of type FileOperations.”

Any ideas if I am going down the right path, and if there’s some documentation I am missing for this?

for `copy {}` you can inject `FileSystemOperations`, and for `zipTree {}` there’s `ArchiveOperations`

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

Are you looking for `ArchiveOperations`?
<https://docs.gradle.org/current/userguide/custom_gradle_types.html#services_for_injection>

replace

```abstract class DownloadStringsTask : DefaultTask() {```
with

```import javax.inject.Inject

abstract class DownloadStringsTask @Inject constructor(
  private val fs: FileSystemOperations,
  private val archives: ArchiveOperations,
): DefaultTask() {```

It’s fine to use the `tempraryDir` as you have, but it might be a good idea to register it as a `@LocalState`

```@get:LocalState
val cacheDir: File get() = temporaryDir```
<https://docs.gradle.org/current/userguide/custom_tasks.html#sec:storing_incremental_task_state>

Oh okay, and this *just works*, no need to even use the Worker API.
Damn, y’all are life savers, I can’t thank you enough!

In order to teach myself to fish as well, instead of just giving me the fish, where in the docs is this ArchiveOperations decsribed? I really couldn’t find it. I am sure it’s because I didn’t know how to properly search for it, but still

I always google `gradle inject services` to find the services

The reason I am using the file here is to store something locally as a download target, then use that file to fetch the content, unzip it and then delete it completely, it’s never supposed to exist before or after the task is done. This @LocalState seems to be used for when state is also persistent across runs no?

as I understand it, that’s basically the point. Gradle will delete LocalState if it ever realises it needs to clear the cache.

Hmm no maybe I misunderstood. Reading the javadoc above it it seems like I want to use it :blush:

Again, thanks so much! You both really came in clutch here :hugging_face:

no problem! Happy to help. Keep the questions coming!

That was easy afterall :sweat_smile: If someone in the future bumps into this thread, here’s how all this looked like as a PR to our repo. <https://github.com/HedvigInsurance/android/pull/1555>. Hope this helps someone.

`@LocalState` should not be necessary though for two reasons.
• the task does not reuse the state in that file, it just overwrites the file if the task is rerun
• the task is not cacheable

"local state" means, that if the task output is taken from the build cache, then this state is deleted, as it is local state of some tool that can work incrementally if that local state matches the output

In the given case, this is just useless :slightly_smiling_face:

Right, thanks a lot for clearing that up. Yeah in my case I’ll just remove it then!
With this said, can I also omit doing `temporaryCacheDir.delete()`  now then? Since I’ll just use `temporaryDir` directly. I am assuming this temporaryDir is something that gets auto-deleted at the the of the task run right? I tried locating where it’s created while the task is still running to ensure that this is the case but didn’t find a way to do so this far.

Actually it is not a "real" temporary dir.
It is not auto-deleted at any time.
If you want to clear it out at the beginning or end of your task, you need to do it yourself.
Otherwise you could also just use a regular JVM temporary directory, that then is cleared out by the operating system.

Alright, seems like I do want to do temporaryDir.delete() at the end of the task then. I don't find a reason to keep those files around.

Is this directory shared potentially with other tasks? If yes I maybe should proactively delete the contents before the task starts too.

the `temporaryDir` for each task is `./build/tmp/nameOfTask`. So it’s not shared with other tasks. I wouldn’t worry about overlapping - Gradle will warn if there’s two tasks are clashing

But it shouldn't hurt to delete in the beginning, maybe your task fail last time before getting to the deletion

So clean in the end to clean up, clean in the beginning to have a clear plate

Or, as I said, just use the normal Java temporary directory.

That task-specific temp directory, is actually more useful for things like local state that you don't have here and that is reused across task executions somehow.

Yes, I see what you mean. And by temporary java directory, I’m assuming you mean `File.createTempFile("lang-file", ".zip")` in my case. Just tested this too and it also just works it seems. Might as well let it be like this then.
~And this should actually get auto-cleared.~ Doesn’t seem like this is automatic, actually :sweat_smile: Anyway, maybe I shouldn’t overthink this, it’s okay regardless.

Whethter it is auto-cleaned depends on your OS.
Linux e.g. will clean it on restart.

Windows will clean it if you are running out of space and manually tell it to clean up things

But you can of course still delete the file at the end of the task or as soon as it is not needed anymore.

Yeah, this is the best all around solution I think too. Delete in the OK case. If my task crashes and the file stays around, not a big deal as it should be deleted eventually anyway (I am on MacOS atm)

there is `File.deleteOnExit()` <https://stackoverflow.com/questions/19012557/use-of-deleteonexit-method-in-java>, but I agree that you shouldn’t overthink it :) Using `createTempFile()` will be fine, unless the file is sensitive, but then _nothing_ about this is sensitive, so there are bigger problems

But be careful with `deleteOnExit`. It is fine for things that currently cannot be deleted because somehow the file is still in use or similar but can maybe be deleted later and if not, then not. But those actions are not guaranteed to be run just like JVM shutdown hooks iirc.

Yes, it actually is implemented as a shutdown hook, so has the same problems / uncertainties

`deleteOnExit()` isn't very timely in the long-lived Gradle daemon anyway

That too, yes. Try to delete, if failed try to delete at JVM exit, if not run or still not possible, corpse.

&gt; The main point is declare really everything what can influence task result as input, ideally by provider.
That is more for task up-to-dateness and task output cacheability.

For configuration cache, you just are not allowed to do certain things at execution time like accessing the `project` or having things as properties that Gradle cannot serialize into the configuration cache.

&gt; I also basically don't understand why configuration cache require such strict requirements on tasks.
The tasks state after configuration is serialized into the CC and the deserialized from there, so some things that cannot be serialized properly just are not allowed and some things like accessing `project` is also no allowed as it might not have the state you try to query as just the tasks state is serialized in CC

With these restrictions, you can then also exeute tasks from the same project concurrently, as they are guaranteed to not influence each others configuration and so on.

&gt; It is possible to create a POJO class and which will contain all required data?
yeah, it should be, if it is either a <https://docs.gradle.org/current/userguide/custom_gradle_types.html#managed_types|Gradle managed type> or it implements `java.io.Serializable` <https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:not_yet_implemented:java_serialization>

Just make sure to annotate the task properties in the POJO with <https://docs.gradle.org/current/userguide/incremental_build.html#sec:task_input_output_annotations|the correct task input/output types>, and use `@Nested` when it’s a task property

To reduce the duplication if you have lots of different specific task types, then you could create some custom task type for all your tasks, and define the POJO as a property

```abstract class MyBaseTaskType : DefaultTask() {
  @get:Nested 
  abstract val myCommonData: Property&lt;MyCommonData&gt;
}```
and then in the plugin you can configure all tasks by type, and add the data - then it’s just done in one place

```project.tasks.withType&lt;MyBaseTaskType&gt;().configureEach {
  myCommonData.convention( ... )
}```

&gt; I have for example many tasks which are run only sometimes and I doesn't need to cache their result.
You could also make them as incompatible with CC, then CC is not used if they are to be executed, but that's by far not the preferable solution

I basically don't need
```  @get:Nested 
  abstract val myCommonData: Property&lt;MyCommonData&gt;```
But to have Properties inside of MyCommonData like
class MyCommonData {
   val version : Property&lt;String&gt;
   val versionCode : Property&lt;Int&gt;
   val commitHash : Property&lt;String&gt;
}

And here I don't know how to create a instance of Property

```interface MyCommonData {
   val version: Property&lt;String&gt;
   val versionCode: Property&lt;Int&gt;
   val commitHash: Property&lt;String&gt;
}```
and then
`objects.newInstance&lt;MyCommonData&gt;()`

Then you get all the automatic Gradle decorations like implemented properties, `ExtensionAware`ness, ...

You can even mark it as `ExtensionAware` explicitly

```interface MyCommonData : ExtensionAware {
   val version: Property&lt;String&gt;
   val versionCode: Property&lt;Int&gt;
   val commitHash: Property&lt;String&gt;
}```

Of course those properties also need the input and output annotations if you use it as `@Nested`

And it will be also automatically serializable?