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

Gradle Community

likely the lib instrumentation variable, it’s enabling instrumentation of classes and the instrumentation lib doesn’t support the Java version they were compiled with (63 -&gt; Java 19).

Java 19 is pretty new, generally find that most things work with Java 17 (last LTS release), beyond that is hit and miss.

Sorry, but I have no idea what you are talking about...

What do the two line I added to `build.gradle` have to do with Java 19?

Some part of the code is being compiled with Java 19.  Part of the test framework is instrumenting that - parsing the compiled bytecode and doodling it with some instrumentation - but that part doesn’t support Java 19.  `PROCESS_LIB_INSTRUMENTATION` enables the instrumentation.

It doesn’t say in that error message.  Perhaps running with `--stacktrace` will tell you the class it can’t handle.

Presumably your code base isn’t Java 19 then?

`PROCESS_LIB_INSTRUMENTATION` is my own defined environment variable...

My code base is Java 8, and why would changing `build.gradle` matter?

that change to build.gradle enables something in the test framework that instruments class files.  It’s tripped across a class file that is Java 19.  Are you perhaps running Gradle with Java 19 (./gradlew --version).

grab the whole stacktrace, that will help with specifics.

So, commenting out the changed lines
```//    environment 'PROCESS_LIB_INSTRUMENTATION','true'
//    environment 'PROCESS_LIB_BUNDLE_LOG_LEVEL','info'```
Causes the same error

huh, that’s different than originally reported.  Anyhow - grab the whole stacktrace and let’s go from there.

What it looks like, is simply changing `build.gradle` causes the error. Reverting the file, everything works fine

interesting.  Can you get a full stacktrace?

How about <https://scans.gradle.com/s/6h2qqwrqhtavi>

My sense is that Gradle is the most fragile build tool I have ever used...

Ok, so you are running Java 19, but it’s Gradle 7.4 that doesn’t support Java 19.

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

Again... when there is no change to the `build.gradle` file, no error...

When I modify the file, the error happens. This is insane regardless of everything else.

expected.  Gradle has cached the compilation of build.gradle.  Changing it doesn’t find a cache entry and requires recompilation, which fails due to Java 19 being installed since last compiled.

Is there a way to tell gradle which JVM to use?

Yes.  <https://stackoverflow.com/questions/18487406/how-do-i-tell-gradle-to-use-specific-jdk-version>

Via `gradle.properties` in your home directory.

Trying, but things do not work as documented...

```./gradlew clean test -Dorg.gradle.java.home=//Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home```
Works, but the properties files do not...

`org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home` in ~/.gradle/gradle.properties

So, as I have mentioned before, Gradle changes so quickly, most of the Gradle tips and trick on the internet are out-of-date...

I don't want to change `~/.gradle/gradle.properties` yet because I am using Java 19 on another project using Gradle 8...

fair enough.  This command:  `./gradlew clean test -Porg.gradle.java.home=//Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home`

The next thing I want to do is upgradle (I made the word up) to Gradle 7.6 for our whole Big Ball Of Mud, because it does support Java 19...

My boss is pretty much on board...

nice.  May want to start by going to Java 17 first, then try 19; as it’s relatively new, newly supported in Gradle, on short term support, and perhaps various plugins etc may have issues.

Java 17 will get some good performance boosts over previous versions.

After upgradling to 7.6, then I will update all our Java to 11... Java 19 is used on a POC project.

It's embarrassing that we still use Java 8, and in some cases, Java 6

indeed.  often work with enterprises that are in the same situation.

I found out recently that I have <https://en.wikipedia.org/wiki/Sensory_processing_sensitivity> which may explain why I find Gradle so frustrating...

interesting.  Will read up on that some more, perhaps I have some of that…

Well, 20% of the population have it... not just people, but other animals too...

&gt; The next thing I want to do is upgradle (I made the word up) 
&gt; 
Actually you didn't, at least the Gradle guys use it too when they update the Gradle build to a new Gradle version. :-)

Btw. you might also consider using JVM toolchains to decouple the Java version used to run Gradle from the Java version used to build and run your code. That way you can use any supported Java version to run Gradle, while you can use a different version for building and running your code.

Thanks, but I already use the toolchains, my problem was that Gradle 7.5.1 does not support Java 19, but I found a way around that.

It does not support running Gradle itself with Java 19.
Using it for a toolchain should hopefully work.
That's one of the reasons for the toolchains' invention afaik.

For my new POC project, I am using Gradle 8, which is fine with Java 19

For the BBOM, I plan to upgrade to Gradle 7.6

Why can't you rename the projects?
They could stay in the same place on disk.
That way manual substitutions should not be necessary.

because renaming the projects would make all command line cumbersome with everything prefixed with `micronaut-`. Not mentioning that it would mean rewriting all project dependencies.

Commandline is imho not *that* problematic, as you can use `m-foo` or `mFoo` and do not have to type it out completely.
But yeah, the dependencies would need to be rewritten once.
Good time to introduce Project accessors maybe? :smile:

I think that would also ruin our GE test execution history model (for predictive test selection)

In any case, I think it's something which should be handled by Gradle directly, via a "mapping rule" or something.

Or not forcing to `${project.group}:${project.name}` but somehow provide another mean to define the coordinates in a composite build compatible way independent from project group and name. Maybe that's worth a feature reuquest if there is none yet. :slightly_smiling_face:

As a slight improvement you could have a mapping file in `micronaut-core` that you could use in the composite build for the mapping instead of parsing the core's settings script. :slightly_smiling_face:

the pb for composite builds is discovering the publications. Currently it misses the fact that the artifact ids are renamed, probably because of how it builds its model. So if instead of tweaking the publications to change the artifact ids, there was something in `settings.gradle` which defined the "project naming strategy" and its mapping to publication coordinates, then it would be an easy win for composites.

I didn't look at the code, just at the docs.
And there it says that you need manual substitution
&gt; When the `maven-publish` or `ivy-publish` plugins are used for publishing, and the publication coordinates don’t match `${project.group}:${project.name}`.
That's why I thought some way independent from project group and name that is supported by composite build is necessary.

because of this issue, I always start new projects with names that I intend to live with Forever (:tm:). But of course that's not a solution for a preexisting project. At least in your world people tend to set the `group`! No one does that in Android-land :sob:

It's there: <https://plugins.gradle.org/m2/gradle/plugin/com/github/johnrengelman/shadow/>

The coordinates changed to
```classpath "gradle.plugin.com.github.johnrengelman:shadow:7.1.2"```
(you can see this in <https://plugins.gradle.org/plugin/com.github.johnrengelman.shadow|the plugin portal page>, legacy plugin application)

(Or open the pom file and follow the dependencies)

Aha! Thank you. Is this a systematic change to how Gradle 7 plugins are published?

Maybe? If it is, it's not systematic, <https://plugins.gradle.org/plugin/com.apollographql.apollo3|our plugin> is still published using the same group as ever.

OK. This plugin has had some inconsistent naming in the past (jengelman vs johnrengelman) so maybe the author's just been fixing that

Yep, it's in the <https://github.com/johnrengelman/shadow/blob/d8117e942b7d98e3274cb1cc9dbb4e4e978a2a58/src/docs/changes/README.md?plain=1#L12|CHANGELOG>

Other than, that, you could also simply use the plugin ID as dependency instead, then you are not affected of changes in the coordinates of the actual code artifact:
```&lt;plugin id&gt;:&lt;plugin id&gt;.gradle.plugin:&lt;plugin version&gt;```
That is also how plugins are resolved from the id in the `plugins { ... }` block

&gt;  This is a technical release. It doesn’t contain any fixes that aren’t included in <https://github.com/JetBrains/kotlin/releases/tag/v1.7.21|Kotlin 1.7.21>.
&gt; Version 1.7.22 of the Kotlin plugin will not be available for downloading or installing in any IDEs.
&gt; 
&gt; — <https://github.com/JetBrains/kotlin/releases/tag/v1.7.22>

Sure, but this doesn’t mean I shouldn’t be able to use it, right?

Maybe this one?
&gt; *tapchicoma*  [10:49 Uhr]
&gt; Those who see variant selection issue on using KotlinGradlePlugin + `kotlin-dsl` plugins after updating to Gradle 7.6 should also add `id("org.jetbrains.kotlin.plugin.sam.with.receiver") version "&lt;kotlin_version&gt;"` into `plugins { .. }` block. <https://youtrack.jetbrains.com/issue/KT-54691/Kotlin-Gradle-Plugin-libraries-alignment-platform|Related issue> that should be fixed in Kotlin 1.8.20 release.

What <@URQ797WRW> posted would also be my next best guess.

&gt; Version 1.7.22 of the Kotlin plugin will not be available for downloading or installing in any IDEs.
I interpreted this sentence as “not being available for downloading” as a general statement, but now that I read it again it could also just mean for IDEs and nothing else.

Indeed, this additional plugin did the job. Thank you!

It’s sad that almost no project out there has a proper platform setup. Only Jackson comes to mind, and they are not even using Gradle. :smile:

rootProject is entirely separate from subprojects, there is no expectation of consistency (unless one applies convention plugins to provide that consistency).  You’ll need to setup the right toolchain on the subproject (Java 19) and provide the options.

I am using
```java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(19))
    }
}```
Is there some option I can set there for `--enable-preview`?

```tasks.withType(JavaCompile).each {
    it.options.compilerArgs.add('--enable-preview')
}```

```tasks.withType&lt;JavaCompile&gt;().configureEach {
    options.compilerArgs.add("--enable-preview")
}```

Okay
```tasks.withType&lt;JavaCompile&gt;().configureEach {
    options.compilerArgs.add("--enable-preview")
}```
works, so does
```tasks {
    compileJava {
        options.compilerArgs.add("--enable-preview")
    }
}```
I was close, but I used
```options.allCompilerArgs += "--enable-preview"```
instead of
```options.compilerArgs.add("--enable-preview")```

The official Gradle documentation is of no help in this regard.

if there are specific areas that are lacking open a ticket referencing them.

It's that they are unwilling or unable to give useful working examples. Unless you are willing to invest in a Ph.D. in Gradle, they consider you a looser.

The style of documentation is just terrible

part of the challenge is that Gradle is uber-flexible - so examples of what?  that’s a very large set of use cases.  They need to move back to supporting standard conventions (use cases) on top of the flexible API (which can be used for much off-label stuff).

So, in the early days of Unix, the documentation was terrible because everything was abstract and ambiguous. Eventually, after many years of complaints, they started adding concrete examples to the `man` pages.

Unless you commit to learning only the Gradle way, they have no use you.

Gradle doc'n is too abstract, and ignores people who learn by concrete...

One thing I like about Maven doc'n is they have more concrete examples, so it's easier to figure out...

Thanks for your help... I don't want to seem ungrateful with my complaining

So, in idiomatic Gradle, I don't want much in the root project. If I have sub-projects, I should do all the work there?

depends on the nature and size of the project.  Say for a Spring Boot app - the root project could be the app itself, and would declare project dependencies on various subprojects that handled various aspects (depending on how you break down modules).  In this example, you’d have some stuff for SB in the root project, and other stuff in subprojects/modules (perhaps some are Java, some Kotlin, etc).  In other examples the root project is simply an aggregator - it has no code at all - pulls stuff in and assembles &lt;something&gt;.

It's also perfectly idiomatic to have only the root project and everything in there imho, if you do not need multiple projects in a build. The builds generated by `init` just follow the convention of having an empty root project and the logic in a subproject so you can easier just add a second subproject if you need it without having to shift things around.

&gt; The style of documentation is just terrible
That's a pretty harsh statement.
In my opinion the docs are pretty great and useful and always help me finding what I need.
They might be terrible for you though, and if you see room for improvement, don't hesitate to open improvement requests in the issue tracker.

Gradle also recently hired a documentation engineer which focus is to improve the documentation experience, so maybe the docs get even better in the forseeable future. You should also fill in his questionaire about the docs to get your voice heard: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1669727966540559>

&gt; Gradle doc'n is too abstract, and ignores people who learn by concrete...
Are you aware that there is not only the userguide, but also example projects and tutorials that are more hands-on?

I am trying to understand how to clean up a Big Ball Of Mud, so everything in the root project is probably a bad idea...

Fair enough, _*for me*_, the docs are terrible. Not at all written in a style that I find helpful. But I am tired of too many people telling me how much they love Gradle... it is very invalidating wrt the problems I am having. People seem unable to acknowledge other people have trouble with Gradle.

Thanks, I just finished the documentation survey...

I am aware that there are example projects, but they are hard to find and generally pretty poor.

One major problem with Gradle is there are two DSLs, and from project to project, document to document, typically, only one DSL is used.

&gt; People seem unable to acknowledge other people have trouble with Gradle.
Sure I acknowledge that.
Would be strange if I didn't, given the time I spend helping people with there problems here and in the forums every day.
I just mentioned that you cannot call the docs terrible in general, when there are many people out there, that have the opposite experience.
Of course they might be terrible for you and I acknowledged that too and suggested how you can get them improved. :slightly_smiling_face:

&gt; I am aware that there are example projects, but they are hard to find
Are they?
There is a dedicated point for them in the left navigation bar, leading to <https://docs.gradle.org/current/samples/index.html> where they are all listed.

&gt; and generally pretty poor
If you think they are poor, again, please send improvement suggestions to the issue tracker so they can get improved.
I cannot say anything about the quality as I never looked at the sample projects in detail.

&gt; One major problem with Gradle is there are two DSLs
I do not fully disagree.
In the beginning there was only Groovy as it was at the time most probably the best way to write a custom DSL.
But it has major drawbacks and then Kotlin was invented and provided a way to write a much better DSL to use (imho).
But you cannot simply switch over, or all existing builds would not work anymore, that would be fatal.
Just always use Kotlin DSL and you will save a lot of headache.

&gt; and from project to project, document to document, typically, only one DSL is used.
Well, in projects it is better if only one is used, except maybe for a transition phase, everything else would be just more confusing.
Good documents - like the Gradle documentation (at least in that regard even if you otherwise disagree) - should simply show both variants, so that a reader does not have to translate.

But if someone writes a blog or SO answer, he typically is too lazy to do that, or the document is simply too old to have Kotlin DSL, but then it is outdated and most probably not valid anymore anyway.
Blame that to the individual author, not Gradle. :smile:

I have to go out soon, so will reply later...

There is no such thing as a precompiled init script, they are distributed as the .init.gradle.kts files and require a Gradle version that can process them and is compatible with what they do.

Really? <https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins> sounds different to me...

Those are precompiled script plugins.  You asked about init scripts.

Yes, <https://github.com/gradle/gradle/blob/master/subprojects/kotlin-dsl-provider-plugins/src/main/kotlin/org/gradle/kotlin/dsl/provider/plugins/precompiled/DefaultPrecompiledScriptPluginsSupport.kt#L72-L75|this> sounded as if also the init script itself could be binary. Anyway, then let's change the scope of my question to the plugin itself: In a Gradle project that only supports Groovy DSL, can I apply a (binary) plugin that has been written in Kotlin DSL via `init.gradle` (which itself is written in Groovy DSL)?

No, plug-ins have runtime dependencies that must be present.  If the target Gradle version pre-dates Kotlin DSL the plug-in will fail to run.

Even is the plugin was a fat JAR (or something similar), bundling all its dependencies?

No.  Gradle provides the runtime environment for plugins, including the Kotlin environment and Kotlin DSL.

Are you sure <@U02S31Y7J2K>?
Yes, Gradle provides the runtime environment, but if you use Kotlin stdlib in a Gradle version that does not care about Kotlin I'd exepect it to work.

And regarding "init script", vs "script plugin", "init scripts" can apply plugins too. And you can pretty well have a `my-foo.init.gradle.kts` precompiled script plugin that then has `Gradle` as target and can be applied to an init script.

Whether it works in a non-Kotlin-aware Gradle you just have to try out. You might also need to then ship the Kotlin DSL part or not use it or something like that.

as an alternative you can try my plugin: <https://melix.github.io/includegit-gradle-plugin/latest/index.html>

But yes, source dependencies can be pretty fine used with Java or Kotlin dependencies.
Basically you have the git-handling wrapper and then it is included like an included build in composite build iirc.

But yeah, the mentioned plugin also has its pros.
And one that can actively work on it.
The built-in source dependencies did not get much love since they were introduced.

Correct, those are deprecated (but still available).  Replacement is to use convention plugins.

Ah, I am trying to understand convention plugins...

But, IntelliJ did not seem to complain when I used `subprojects { . . . }`

It’s still available but strongly discouraged to use.

I discuss it at a high level in this post <https://developer.squareup.com/blog/herding-elephants>

I'm writing a custom convention-settings-plugin based on this one: <https://github.com/cloudflightio/autoconfigure-gradle-plugin/blob/main/src/main/kotlin/io/cloudflight/gradle/autoconfigure/AutoConfigureSettingsPlugin.kt|https://github.com/cloudflightio/autoconfigure-gradle-plugin/blob/main/src/main/ko[…]cloudflight/gradle/autoconfigure/AutoConfigureSettingsPlugin.kt>
I have two questions regarding this:
1. the reckoned version is applied to all subprojects using `settings.gradle.allprojects { project -&gt; project.version = developmentVersion }`, is this good practice in this context? And if not, what would be the correct way to apply the version for all projects?
2. The `GrgitService` is registered with `spec.maxParallelUsages.set(1)`. In the <https://docs.gradle.org/current/userguide/build_services.html#concurrent_access_to_the_service|documentation> it is mentioned, that "the build service must be registered with the using tasks via Task.usesService(Provider&lt;? extends BuildService&lt;?&gt;&gt;)". But in this case the build service isn't used within a task, but within the plugin directly, is there anything to do in this case for the `spec.maxParallelUsages` to take effect? Or is it even useful conceptually?

I personally prefer the delegates' usage over string-y methods generally.

The `this@Build_gradle.` that is necessary is a bit unnice, but that's because those extensions have same-named properties. A rename e. g. of the property could maybe mitigate that.

Actually, I would probably not have those values in the properties file, but directly in the build script if I were to write the build script myself unless I want to be able to override them via `-P` or the user-specific properties file. But I guess this is that the typical consumer does not need to read and understand and modify the build script, but just do the configuration in the properties file.

Thanks for sharing your thoughts, <@URQ797WRW>.
The purpose of moving all potentially modifiable values in the `gradle.properties` file is indeed to keep the configuration as simple as possible.

As I understand the benefit of having each variable defined separately – you can define its type explicitly, no magic involved… This approach produces a verbose header to the file when you have ten properties.

I could probably turn into this direction faster if this would be possible:
```val platformPlugins: List&lt;String&gt; by project```
but:
```* What went wrong:
class java.lang.String cannot be cast to class java.util.List (java.lang.String and java.util.List are in module java.base of loader 'bootstrap')```

Yeah, no, there is no auto-coercion into other types.
It also gives "extra" properties which could be any type so there a different type would make sense.
For the properties from the properties file, they are always `String` unless maybe you invent an own delegation method that would support such type coercions.

So in this case the type declaration is not really the most relevant.
Opposed to your solution the new one would complain if a property is not set though.
And I personally just prefer to have such delegates, to for example easier be able to make renames and not forget a place where the name is used as `String` and so on.

The approach with the delegates does not have to be made as "header", you can also declare the properties near the place where you use them instead of all in the beginning.

Hi Team anyone Please help me to solve how to add bom dependency in version catalog

A version catalog doesn't care if it's a BOM or something else. It's at the declaraton site that you'd use the bom:

```dependencies {
    implementation(platform(libs.bom))
}```

The `kotlin-dsl` plugin version for Gradle 7.6 is 2.4.1

I had not defined the version, so I supposed that would not be the issue.
I ve change it to this
```plugins {
    id("org.gradle.kotlin.kotlin-dsl") version "2.4.1"

}```
and the problem still persists. The strange thing here is that I still get this log:
```This version of Gradle expects version '2.4.1' 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.```

Found the problem. The version was defined somewhere else statically... Thank you for your help :slightly_smiling_face:

I am getting below exception while trying to refer version catalog dependencies, anyone please help

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, you try to create a version catalog "from" an artifact that is not a published version catalog, but a normal Java library.

Hi :slightly_smiling_face: What could causes resolveAndLockAll to hang and how would I go about debugging it?

You probably mean provider, not property?
```copyTaskProvider.map { layout.dir(provider { it.destinationDir }).get() }```

But if you control the consumer, you also might have other options: <https://discuss.gradle.org/t/implicit-task-dependency-on-directory/44363>

Ahhh yes provider, that worked. Had to re-arrrange it a bit to
```layout.dir(copyTaskProvider.map { it.destinationDir })```

Unfortunately we don’t control the consumer here, so we had to explicitly add a dependency as well

You don't need to add a dependency explicitly if you do not rearrange my version

Ahh so that’s the difference. I’ll try to get my head wrap around why your version has implicit dependency. Thanks!

The task provider carries the dependency.
But with `layout.dir` this dependency is not "copied" over but breaks the dependency

That's also why you cannot do
```copyTaskProvider.flatMap { layout.dir(provider { it.destinationDir }) }```

Because with `flatMap` the outer provider is replaced by the inner provider and the inner provider has no task dependency

Wow that’s a short and concise explanation. If I want to try to dive deep into that where could I find this `TaskProvider` implementation or documentation?

What is "that"?
The implicit task dependencies?

I think the main documentation about it should be at <https://docs.gradle.org/current/userguide/lazy_configuration.html>

Not sure where the implementation is, but probably somewhere in `ProviderInternal` or something along those lines

Thanks a lot! Yeah have gone through those documentation multiple times and sometimes have to read between the lines for these kind of details.
&gt; The task provider carries the dependency.
&gt; But with `layout.dir` this dependency is not “copied” over but breaks the dependency

I wouldn't integrate Kythe with Gradle that way (despite that being what the Kythe doc says), it probably worked with older versions of Gradle, but no longer.
Something you could try:
```tasks.withType(JavaCompile).configureEach {
    doFirst {
        exec {
            executable '/opt/kythe/extractors/javac-wrapper.sh'
            args options.allCompilerArgs
            environment 'KYTHE_EXTRACT_ONLY', true
        }
    }
}```
(be careful if you use toolchains, you'd have to also set the `JAVA_HOME` environment variable)
I think it would be much better as an individual task but that `doFirst` should work as a POC.

I don't think the original suggestion is bad. I think that's a case for which `forkOptions.executable` exists.

But I also noticed that it clashes with the newer toolchain integration nowadays.

<@U02RS54EWMA> I think adding this fixes the issue:
```javaCompiler.convention(null as JavaCompiler?)```

IIRC I saw the same issue when creating this sample:
<https://github.com/jjohannes/understanding-gradle/blob/main/22_The_JavaCompile_Task/my-build-logic/java-plugins/src/main/kotlin/my-java-base.gradle.kts#L19|https://github.com/jjohannes/understanding-gradle/blob/main/22_The_JavaCompile_Tas[…]uild-logic/java-plugins/src/main/kotlin/my-java-base.gradle.kts>

At some point before Gradle 7.6 passing an arbitrary executable to the `executable` property stopped being supported.

For `compileJava` the property is intended to accept a path to a valid `javac` that is a part of a valid JDK installation. In other words, a toolchain was inferred from this path, and then used.

Starting from Gradle 8.0, toolchains become the main and only way of configuring executables for core JVM tasks. Previously, toolchain tool properties such as `javaCompiler` were optional/nullable. With Gradle 8.0 a tool (a compiler in this case) will always be present, and setting it to null will lead to errors.

<@U023HSZL88M> What was the reason you were trying to set the compiler to null?

<@UDC9Q9RD0> - It seems to work, thanks! I will also give it a try with tool chains and see how it works.

<@U023HSZL88M> - This didn’t work..not sure why but I get the same error

<@U03K4EQUDQF> I just wanted to demonstrate (see the video) that you can set the "executable" as one option to make the JavaCompile task fork a separate process. It did not work without doing this (but maybe that is because I also configured a toolchain).

<@U03K4EQUDQF> If you remove the option of setting an executable completely, there should really be done something here:
<https://github.com/gradle/gradle/issues/15942#issuecomment-1316817116>

Right now, it's the only sane way to use the Eclipse compiler. I think you shut a lot of folks out, if you remove that without replacement. :confused:
(As I said already in the Gradle internal Slack to Louis, I am happy to meet about that topic to see if we can help there further)

<@U02RS54EWMA> sorry that that didn't help. Wrong guess from my side then.

I guess the problem here is that `javac-wrapper.sh -version`, as called by default by Gradle to determine the Java version of the toolchain, does nothing (possibly fails). One possibility is to change the script to make it work, or ditch the script and do that same in pure Gradle (more or less what I proposed)

That makes sense. Thanks for the explanation <@UDC9Q9RD0>.

<@U023HSZL88M> The executable option availability and usage in Gradle 8.0 is unchanged compared to Gradle 7

Thanks for clarifying. I misunderstood then. Can you elaborate (or link some docs) about what the practical consequences of this are then:
&gt; Starting from Gradle 8.0, toolchains become the main and only way of configuring executables for core JVM tasks.

<@U023HSZL88M> Mainly that toolchain-related properties on the tasks, such as `CompileJava.javaCompiler` are not optional anymore, and it’s not possible to set them to null.
Previously, not all core JVM tasks were using toolchains in all cases. With Gradle 8.0 even if you configure `executable` or `javaHome`, they will resolve into a toolchain.

But didn't you just said behavior will not change compared to Gradle 7?

Currently you can set an `executable` and do `javaCompiler.set(provider { null })` to make the `executable` be used.

If that goes away with Gradle 8, also this is a must-have for us to upgrade: <https://github.com/gradle/gradle/issues/16245>

Otherwise you cannot use a non-detected toolchain that you for example build in the current build run

The toolchain provisioning SPI does not help for that

&gt;  But didn’t you just said behavior will not change compared to Gradle 7?
I was referring to the `executable` setting in the `compileJava` task specifically. There, nothing is really changed apart from the fact that `javaCompiler` property will be set whatever toolchain is configured via the `executable` . Previously, the `javaCompiler` would keep having the `null` value if you query it.

Oh, so you can set `executable` and the `javaCompiler` will be calculated from the `exectuable` value?

&gt; Currently you can set an `executable` and do `javaCompiler.set(provider { null })` to make the `executable` be used.
<@URQ797WRW> I am not sure I understand what you mean.

It should be enough to set `options.fork = true` and `options.forkOptions.executable`, no need to nullify the compiler property. Unless the toolchain is configured on the `java` extension as well.

&gt; Oh, so you can set `executable` and the `javaCompiler` will be calculated from the `exectuable` value?
Yes, and it will override the toolchain configured on the `java` extension as well (Starting with Gradle 8.0)

Yes, if you currently have a toolchain in the `java` extension
but need a task to use a different executable.
Then you currently need to set the `executable` and additionally set the Java tool property to a `null`-producing provider otherwise the `executable` is ignored.

You can find more technical details for this change here:
<https://github.com/gradle/gradle/pull/22108>

&gt; Yes, and it will override the toolchain configured on the `java` extension as well (Starting with Gradle 8.0)
You set an `executable` for one specific task and that will set the toolchain of the whole Java extension? o_O
I don't think I like that change.
Seems the worng way around.

&gt; You set an `executable` for one specific task and that will set the toolchain of the whole Java extension? o_O
Sorry to confuse you. It will override the toolchain for the task. The extension-level toolchain stays untouched.

I mean the “override” in a sense of priority of what gets selected for the task in the end.

Ah, ok, then it sounds perfect, thanks for the clarification. :-)

Thanks for explaining <@U03K4EQUDQF>. Makes sense and sounds like a great unification/simplification in this area.

Hey all, does anyone know how to fix this testSuite error? `Cannot create a TestSuite named 'JvmTestSuite' because this container does not support creating elements by name alone` ?

actually i figured it out, was building with gradle 6 instead of 7

You should at least provide the error you get and if possible maybe even an <https://stackoverflow.com/help/mcve|MCVE>

*Please find, Getting this Exception* ,      Could not resolve all artifacts for configuration 'incomingCatalogForLibs0'.
&gt; Could not resolve com.test:test-catalog:0.7.0-SNAPSHOT.
  Required by:
      unspecified:unspecified:unspecified
   &gt; Could not resolve com.test:test-catalog:0.7.0-SNAPSHOT.
      &gt; Could not parse POM /Users/sanman/.m2/repository/com/test/test-catalog/0.7.0-SNAPSHOT/test-catalog-0.7.0-SNAPSHOT.pom
         &gt; Could not find software.amazon.awssdk

2.17.276.
           Searched in the following locations:
             - file:/Users/sanman/.m2/repository/software/amazon/awssdk/bom/2.17.276/bom-2.17.276.pom
           If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration

You have a dependency on `software.amazon.awssdk:bom:2.17.276` and have only the repository `mavenLocal()` declared (which should optimally never be used actually) and there it is not found

Thanks for response. I am used `mavenLocal()` for testing form my local. so you mean combination of publishTomavenLocal(for version catalog)  and rio-library  is not working for local testing. when we deploy to remote repository if we uncomment rio-library(guava and gson) plugin it is working right ?

I don't know, I don't know your project. I just interpreted your error message. And that says, that you have *only* `mavenLocal()` as repository for resolving dependencies and there your dependency is not present.

build.gradle

settings.gradle

&gt; 403 Forbidden
So I guess you tried to access with a user that does not have the right to

Hey, <@U01984J3GJF>! There are a few things I see that could be wrong:
1. What <@URQ797WRW> mentioned above :point_up: is likely. Regarding configuration, we recommend only enabling anonymous build cache _read_s and not _writes_ and I see you have `push = true` defined in the settings.gradle. Granted, the error you are seeing seems to be a read, but it is something to look into. 
2. It looks like there is more than one configuration defined for remote build cache in the settings.gradle file. With Gradle Enterprise, you only need the block that uses `gradleEnterprise.buildCache`.
3. In the build.gradle file you have a block for `buildScan`. I don't recognize this block, but it's contents look more like what you should be defining in the `gradleEnterprise` block of the settings.gradle file.

You may find these Gradle Enterprise build configuration samples we have useful.
• <https://github.com/gradle/gradle-enterprise-build-config-samples/tree/7e02df6fcbfd85c3e8d507607146f79f12d5002c/common-gradle-enterprise-gradle-configuration-groovy|Groovy>
• <https://github.com/gradle/gradle-enterprise-build-config-samples/tree/7e02df6fcbfd85c3e8d507607146f79f12d5002c/common-gradle-enterprise-gradle-configuration-kotlin|Kotlin>

The `buildScan` block is from ancient versions of the Gradle Enterprise plugin.
If you go to `<http://scans.gradle.com|scans.gradle.com>` and select `Gradle &lt; 4.3` you still see it there.

Ah, I figured something like that was the case. Much before my time. :slightly_smiling_face: Thanks for pointing that out.

Thanks again for your help folks! We were able to get things working

Can you add `systemProp.gradle.enterprise.testretry.enabled=false` to your `gradle.properties` and check if the issue still persists (<https://docs.gradle.com/enterprise/gradle-plugin/#test_retry_migration|docs>)?

It tries to read the JAR as JaCoCo execution data which cannot work.
But without you providing details, optimally an MCVE, there is not much we can do to help.

I have two modules: server and interface
plugin i included is id ‘jacoco-report-aggregation’
and no extra config is added in my build.gradle for server module.
No config has been added in interface module.
It works fine if i am generating jacoco report for server only using the following configs:
```jacoco {
    toolVersion = "0.8.8"
    reportsDir = file("$buildDir/jacoco")
}

jacocoTestReport {
    dependsOn test
    sourceSets sourceSets.main
    additionalClassDirs(configurations.runtimeClasspath.filter{it.path.contains(rootProject.name)  })
    executionData fileTree(project.rootDir.absolutePath).include("**/build/jacoco/*.exec")
    reports {
        html.outputLocation = layout.buildDirectory.dir('jacocoHtml')
        xml.enabled false
        csv.enabled true
    }
}```


I am confused what configs i need to pass for agregating reports

It should just work out of the box.
If it doesn't as I said, please provide an <https://stackoverflow.com/help/mcve|MCVE> so that someone could maybe see your error if you didn't find it already while trying to create it

Hey <@URQ797WRW> if one module doesnt have test cases but i try to aggregate the report so should it fail ?

and does aggregate gets report from jar the gradle makes or it will run test cases first to get results

No, the aggregation logic would mitigate modules without tests.
The JaCoCo reports are not in jars and couldn't be deterimined from the jar.
It will run the test cases and aggregate the proper results.

I don't think there is something built-in.
But you can probably easily write a task that gets `outputs.files` on all tasks and checks whether a specific file is part of it, then outputs that tasks path.

Maybe make a task of type `DefaultTask` instead (not giving a type) and use the `copy { ... }` closure instead. Be sure to still define the inputs and outputs.

Thanks for reminding me of the `copy` closure. That helped me solve it in the buildscript (although I should probably extract it into a task).

```tasks.register('extractCorpus') {
    dependsOn(configurations.corpus)

    def destinationDir = layout.buildDirectory.dir("corpus")

    inputs.files(provider { configurations.corpus })
    outputs.dir(destinationDir)
    outputs.cacheIf { true }

    doLast {
        copy {
            into(destinationDir)

            configurations.corpus.each { file -&gt;
                into(file.name.substring(0, file.name.lastIndexOf("."))) {
                    from(zipTree(file))
                }
            }

        }
    }
}```

You register the extension and immediately query its value without giving the consumer the chance to configure the extension, so you of course see the default value.

The *bad* solution you might find online would be to use `afterEvaluate`.

The proper solution is to use the lazy api you defined lazily.
So for example wire the property to a property on a task so that it is only queried at task execution time.
If you really need the value at configuration time, add a function to your extension instead that consumes and handles that value.

Btw. as it is called `filePath`, you should probably use `RegularFileProperty` instead.

Can you point me to some documentation? A lot of what you said is unknown to me

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

Hello. I've been playing with the Gradle tooling API using ProgressEvents and custom models. One thing I'm not sure how to do: is it possible to send custom ProgressEvents from the build to the controller through the connector? Looks like the StatusEvent type could be a good candidate to send something quite generic.

You are running with JRE, but the requirement is JDK, and check your `JAVA_HOME` environment variable （已编辑