I am using kotlin convention plugins and see this warning:

> Task :buildSrc:compileKotlin
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target
w: Inconsistent JVM-target compatibility detected for tasks 'compileJava' (23) and 'compileKotlin' (22).
This will become an error in Gradle 8.0.

Scan: https://scans.gradle.com/s/amckdnzxgc3ni What is the best way to handle this? Setting

kotlin.jvmToolchain(22)

fixes it on windows, but on arm mac it can't find a toolchain. Is there some specific java version recommended? Scan from mac: https://scans.gradle.com/s/ritdchcfwbajy I do have foojay toolchain plugin setup for this project

Set the jvmTarget (Kotlin) and the source and target compatibility (Java) to use the same version

Your Mac scan clearly states > No locally installed toolchains match and toolchain download repositories have not been configured. > So no, you don't have the foojay properly set up, it it should work. There are arm Mac Java 22 distributions: https://api.foojay.io/disco/v3.0/packages?package_type=jdk&latest=available&version=22&operating_system=macos&architecture=aarch64

foojay is setup and has been working, it is set in the root project's settings.gradle.kts

plugins {
    id("org.gradle.toolchains.foojay-resolver-convention") version "0.9.0"
}

foojay is setup and has been working, it is set in the root project's settings.gradle.kts

Well, I can just interpret what I see. And the Mac build said it is not configured for

buildSrc

which is also confirmed by the build scan which shows that the foojay convention plugin is not in the build dependencies of the

buildSrc

build.. What you have in the root project is not so relevant. If you want to use an auto-provisioned JVM toolchain in the

buildSrc

build, you need to configure it there, it is a separate build.

to buildSrc's settings.gradle.kts does not seem to download the toolchain https://scans.gradle.com/s/kkbgyzueqk7hy

That scan also does not look like you applied the plugin in the

buildSrc

build. And the error you get is a different one. You have a dependency on something that needs at least Java 22 while you use Java 21 for building, which also suggests that you did not configure a Java 22 toolchain for the

buildSrc

build, but use the JVM running Gradle which in this Scan is a Java 21.

the only kotlin in the project is the build scripts

That's not really true. You have precompiled script plugins in Kotlin DSL and a Kotlin class in

buildSrc

. And

buildSrc

building is where the message comes from as there you use a Java version not compatible with the Kotlin version you use for that.

Considering that the original deperacation warning said gradle 8.0 but I am on 8.12 is what is confusing me.

That probably means you are lucky and it was planned to become an error in Gradle 8 but was moved to a later point in time while not adjusting the message to mention a later version. This I'd recommend you report as bug to Gradle, because that makes no sense at all.

How do I apply the the toolchain and autoprovisioning to buildSrc?

The same you do it on the main build.

buildSrc

is a completely standalone build that just "happens" to be built before your main build and the result put in a class loader that is the parent of the root project classpath class loader

So I can't do it the exact same way with a version due to this issue, removing the version from foojay for buildSrc fails with the previously linked scan - the java 22 dep is from me specifying the kotlin toolchain, if I remove that everything works

Ah, forgot about that issue, so yes, without version. Can you push the version that "fails with the previously linked scan"?

It is here <https://github.com/AstroImageJ/astroimagej/tree/dev/kotlin-script> (renamed the branch from last time)

Btw. you could probably consider using an included build instead of

buildSrc

, then at least that issue you just linked to should not hit you 🙂

I thought those didn't work with convention plugins? I might be misremembering though

What do you call "convention plugin"? A convention plugin in the real meaning is any plugin that employs your conventions, no matter how it is implemented or whether it is in

buildSrc

, an included build, or published somewhere. If you talk about the

...gradle.kts

files, those are "precompiled script plugins" which is a popular way to write convention plugins. But either way, whatever you can do in

buildSrc

you can also do in an included build and I'd usually always would prefer those. Actually, there are a few exceptions, like when you need to monkey-patch a 3rd party plugin class which you can only do from

buildSrc

. Well, no even that you can do from an included build if you add it to the settings script classpath.

yes, I meant the precompiled script plugins (in this case the

aij.*-convention

files)

Yeah, those are convention plugins implemented as precompiled script plugins. And I'm not aware of any problem having them in an included build.

I'm giving it a try, have to move where I use the ValueSource definined in the included build is used out of the main buildscript, probably would need to be done anyway for isolated projects

I didn't look at implementation, so cannot say anything regarding IP or anything, but if you mean because of the class not being found, you just need to add it to the classpath, for example using

id("aij.java-conventions") apply false

. But unfortunately the error persisted.

I only put 22 as that was what the warning message was saying it changed to is there a good java version to target?

For

buildSrc

the lowest you want your build to support running with. As you restricted this to Java 11+ because of JGit, Java 11 is probably a good choice for

buildSrc

. Otherwise Java 8 as that is the lowest version supported by Gradle currently.

that seems to have works, thanks!

They are running in parallel:

huh, the scan I saw made it look sequential.

Yes, but it is not caused by the unzip tasks

download should be parallel though, I see all the files being downloaded at the same time

Interesting, not for me:

I've skipped the individual package tasks via `onlyIf {false}`https://scans.gradle.com/s/qg7e63fozk2nm/timeline and running it via

packageAij

The only thing about that snippet I see is that

outputs.upToDateWhen { false }

is pretty much non-sense as it is no-op. The task does not have actions anyway. And even if it would have, that would not be the right way to make it "always out-of-date".

we don't normally run them all individually like that, it's either running 1 task or

packageAIj

for everything

Yeah, but I don't see why there should be a difference regarding parallelizability

Neither do I, but I also don't fully understand what make gradle decide that

Maybe a bug

possibly, no worries then, thanks for all the help!

Well, if it is a bug, you should report it 😉

I'll work on making a minimum reproducer another day to make an issue

But also interesting, that with the download task they run in parallel if they run transitively, but sequentially when called explicitly, while with the unzip tasks they run sequentially if they run transitively, but in parallel when called explicitly.

yeah, it's very odd

But besides of that strange behavior, that the tasks do not run in parallel seems to be related to the package tasks somehow. If I replace the package task registration by

tasks.register(packageTaskName)

the unzip tasks run in parallel

you mean removing the

.named

part where I added the deps?

No

oh, why would that effect the zip tasks?

I don't know, obviously it does not affect the download tasks.

sure, sounds like 3 bug reports at this point

Ah, no, that's actually quite clear

oh, that's annoying is there a way to work around this?

Make the task CC compatible 🙂

I had started on a PR to the plugin for that, but then ran into that issue with

ArchiveOperations

documentation being wrong. I don't want to go adding deps to his plugin without talking to him first so a custom

Sync

task with the worker API?

So I find it still strange that the download tasks are not run in parallel when called explicitly, but that is probably not a CC issue, but a worker-api issue. Oh, unless specifying the tasks on the commandline controls order of the tasks. This would explain that they are not run in parallel then.

sounds fun, I'll give it a try. If it doesn't seem easy, this isn't the worst