This message was deleted.

Why is JandexMain executed through

javaexec

? Could you maybe rewrite it to use the Worker API? You could get the same kind of isolation but also classes from the plugin.

Well, I’m not familiar with the Worker API to begin with. Also, in its early days the API had issues thus I stayed clear of it. If it’s more stable now I guess I could switch to it. Do you know any good examples to get started with such API?

I feel like the docs themselves do a rather good job at how to get started (with the addition of javadoc and/or IDE autocompletion). Here you'd probably use classLoaderIsolation, possibly processIsolation.

See https://github.com/vlsi/vlsi-release-plugins/blob/45865c3186a7ecc0d30b1f88c2f31160b5e1b13a/plugins/jandex-plugin/src/main/kotlin/com/github/vlsi/jandex/JandexTask.kt#L85 😉

@Vladimir Sitnikov Why did you use

.await()

with that error handling here?

Maybe as a quick fix you might be able to find original (not-instrumented) plugin jar from buildscript classpath. So if you are able to pass

project.buildscript.configurations.getByName("classpath")

to a task and then do smth. like:

buildscriptClasspath.find { it endsWith "jandex-gradle-plugin-.*.jar" }

I see that in

buildscript.configurations.getByName("classpath")

artifacts paths are in “repository cache”

~/.gradle/caches/modules-2/files-2.1

and not in “instrumented cache”

~/.gradle/caches/jars-9

that you get when you do

SomeClass.class.protectionDomain.codeSource.location

. I didn’t test it though. 🙂

@Anze Sodja I don’ think that’s a solution. The root cause for this change is a CNFE triggered by missing classes/annotations on the compiled plugin classes. Gradle 7.5 now performs some transformations that were not there before