https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
c
Seems like the plug-in is depending on Gradle internal classes (directly or indirectly) that have changed (moved or removed) between Gradle versions.
Likely an issue with a transitive dependency getting pulled in that isn't compatible with Java 18 (not surprising as jandex is indexing class files). Compare the build scan output (dependencies list) and check dep versions.
a
Jandex does not depend in Gradle. The plugin was compiled with Gradle 6.9.1 IIRC. This the only change in dependencies is the Gradle version (7.5-rc-1) used by the consuming project
I don’t have a clue on how the plugin might depend on internal classes, look at the imports
c
It's reading class files via jandex, tripping over something on the class path that contains that class.
Could add some debug statements to show which class file is being read when the exception occurs.
a
I get that. The class at fault must be Gradle specific
c
Yep. Something pulling in an incompatible chunk of code. Knowing what class file is referencing that will help identify the cause.
v
The issue linked to in the ticket should already be the problem. This is usually not a Gradle "bug", but an intended behavior that causes problems if the Plugin does a bad action. The "bad action" is if the plugin uses its runtime class path outside of Gradle. For example if it determines its own class path and then runs some tool like Jandex with it.
Gradle does byte-code transformation of the plugin class path to find violations of configuration cache compatibility or automatically handle reads of system properties as configuration cache input and so on.
This byte-code transformation is not done on each run but it is done once and saved to disk so that it is not done each time the build is run.
If you then use those manipulated jars outside of the Gradle context, the woven in Gradle internals fail to be found with exactly that message.
As it works with 7.4 and fails with 7.5, there is most probably some additional tranformation done that hits the classpath now and didn't hit it before.
a
Wrong. The plugin does not use its runtime classpath. It reads the compiled classes from the output of the main sourceSet
v
I just say how this error usually happens, didn't investigate deeply in your plugin 🙂
a
Shooting from the hip is usually wrong
v
I have other experience 😉
a
I read the linked issue and saw that the problem for that reporter was indeed reading the plugin’s classpath. I understand how that can cause trouble. However, in this case the plugin reads the compiled output using standard file i/o APIs. Is there now in 7.5 a different way to do this?
v
In the main classes output there should not be this class, unless you use it yourself which is unlikely I'd guess.
Do you have an MCVE where this happens?
a
Apparently creating a fresh new Quarkus project (via code.quarkus.io), with Gradle 7.5, jdk 18, and the latest version of the jandex plugin is enough to trigger this issue
v
private FileCollection resolveClasspath() {
project.files(
new File(JandexMain.protectionDomain.codeSource.location.toURI()).absoluteFile,
classpath)
}
There it resolves a jar from the plugin class path and then uses that in a 
javaexec { ... }
. One point for the hip. 😉
a
FML. Indeed
So, Jandex + its dependencies (if any) must be loaded to run the javaexec process. But the way it’s done it’s not good with 7.5. Should it be done with a Configuration?
v
Instead for example use a detached configuration to resolve Jandex outside of Gradle class path context, or if you want the user to be able to control the dependency, you can even create a named configuration with the dependency as default dependency, so that the user could overwrite it.
Please do not unconditionally register a repository to ensure it can be resolved. This would conflict with 
FAIL_ON_PROJECT_REPOS
, at most make it optional or just require the user configured a repository where the dependency can be found.
a
The plugin already offers an option to manage the jandex version. Switching to a detached configuration may be the ticket to fix this issue
oh yes, no implicit repos. I learned that lesson years ago
👌 1
v
Switching to a detached configuration may be the ticket to fix this issue
Having a named configuration has the advantage, that the user can specify a complete different dependeny, like changed coordinates of Jandex in the future, or an own fork and so on. I think the code quality plugins do it like that. They provide an extension property to configure the version, this version is used for the default dependency of the configuration, but if a user defines own dependencies for that configuration the default dependency is not considered.
Just as a thought. 🙂
a
A named configuration plus default dependency? If so the configuration must be resolvable and visible, right?
v
visible
for a configuration is extremely misleading. It is part of the legacy approach to define artifacts. The 
assemble
task creates all artifacts that are attached to configurations that are 
visible
. So iirc you should practically always have it to 
false
nowadays.
But 
resolvable
yes, you want to resolve it, so don't forget to it to 
consumable
false. The default is 
true
for both due to backward compatibility but that combination is legacy too.
a
Well know I’m confused. I thought visible meant users could refer to it in their build scripts. Now I must set visible & consumable to false? While keeping resolvable to true?
v
Yeah, that is confusing, as I said, the name is very unlucky chosen. I had the same thought for years until I learned differently. Users can always refer to them in their build scripts. It means in the legacy world "visible to downstream" or however you call it. So yes, if I'm not mistaken it should be visible false, consumable false, resolvable true. You can just leave resolvable at its default or you could set it to true for clarities sake.
Actually as long as you don't attach artifacts to the configuration I think it shouldn't matter what 
visible
is set to. But I just always set it to 
false
nowadays unless I have a good reason not to.
a
Oh well, thanks
v
You're welcome
7 Views
Open in Slack
PreviousNext
Powered by