This message was deleted.
# community-supports
Slackbot
08/31/2023, 8:26 AMThis message was deleted.
v
Vampire
08/31/2023, 8:47 AMSet a breakpoint to its finalization?
Either in the Gradle code, or set it to some provider in time that you then can set a breakpoint to.
Or if not a breakpoint, then logging a stacktrace in that provider.
Then you should hopefully see where the request comes from.
m
melix
08/31/2023, 8:53 AMI'm not even sure how it's possible to set a breakpoint precisely to that property... It's the standard
java.languageVersionc
Chris Lee
08/31/2023, 8:56 AMIt’s likely that something else, outside your plugin, is eagerly resolving / finalizing that property.
m
melix
08/31/2023, 8:56 AMI suspect it's caused by use of evaluationDependsOn, which I still need... If so this is going to be a nightmare to solve.
v
Vampire
08/31/2023, 9:15 AMYeah, probably not to a specific property in the Gradle code.
Hence my suggestion to set the value at some place where it still works to some provider so that you can in that provider set a breakpoint or log a stacktrace.
m
melix
08/31/2023, 9:35 AMcan't even find a place where I can set one 😠
v
Vampire
08/31/2023, 9:38 AMIn the Gradle code you mean?
m
melix
08/31/2023, 9:39 AMin my code. Even if I do a
pluginManager.withPlugin("java") { ... get the java extension and set a dummy provider ... }v
Vampire
08/31/2023, 9:40 AMHm, seems someone else is setting it afterwards then? 😕
m
melix
08/31/2023, 9:40 AMthis is extremely painful to debug 😞
v
Vampire
08/31/2023, 9:42 AMMaybe you can set a breakpoint in
AbstractProperty#finalizeNowdisplayNamem
melix
08/31/2023, 9:42 AMyeah I'm trying to find one place, there are many finalize calls...
melix
08/31/2023, 9:43 AMasynchronous calls don't make it easy either since the stack trace doesn't refer to the original code 😞
melix
08/31/2023, 9:43 AMe.g
melix
08/31/2023, 9:44 AMI have a call where a
languageVersionmelix
08/31/2023, 9:46 AMcool, this is the line which triggers finalization:
project.getPluginManager().apply(JavaBasePlugin.class);
v
Vampire
08/31/2023, 9:46 AMfinalizeValueOnReadfinalizeNowm
melix
08/31/2023, 9:47 AMI'm in
finalizeNowv
Vampire
08/31/2023, 9:47 AMcool, this is the line which triggers finalization:
> project.getPluginManager().apply(JavaBasePlugin.class);🤨
m
melix
08/31/2023, 9:47 AMyup
melix
08/31/2023, 9:48 AMthis one, or the groovy plugin. w.t.f.
melix
08/31/2023, 9:50 AMI think I have found the culprit:
Copy code
conf.attributes(attrs -> compileClasspathAttrs.keySet().forEach(key -> {
Object attribute = compileClasspathAttrs.getAttribute(key);
//noinspection unchecked
attrs.attribute((Attribute<Object>)key, attribute);
attrs.attribute(Usage.USAGE_ATTRIBUTE, project.getObjects().named(Usage.class, JavadocAggregationUtils.AGGREGATED_JAVADOC_PARTICIPANT_DEPS));
}));melix
08/31/2023, 9:50 AMthis is the behavior of copying attributes which changed in 8.3
melix
08/31/2023, 9:51 AMI really don't like such behavior changes in a minor 😞
v
Vampire
08/31/2023, 9:52 AMMaybe they were unintended. Wouldn't be the first that right away gets reverted in an 8.3.1
m
melix
08/31/2023, 9:52 AMthey were intended
melix
08/31/2023, 9:53 AM<rant>This wouldn't happen if there was a public API to copy attributes from one configuration to the other</rant>
melix
08/31/2023, 9:54 AMyeah, problem fixed. Completely unrelated code, in a completely different place. Easy to fix 🙂
v
Vampire
08/31/2023, 9:54 AM👌
Vampire
08/31/2023, 9:54 AMHappy to be your rubber duck 🙂
m
melix
08/31/2023, 9:54 AMtx 🙂
2 Views