https://gradle.com/ logo
Join Slack
Powered by
Hi all - trying to use plugin <net.idlestate.gradl...
# community-support
r
Hi all - trying to use plugin net.idlestate.gradle-duplicate-classes-check with the configuration cache, and they do not play nicely together. Stacktrace & details in thread.
I get this stack trace:
Copy code
groovy.lang.MissingPropertyException: No such property: name for class: org.gradle.api.internal.file.DefaultFileCollectionFactory$ResolvingFileCollection
        at net.idlestate.gradle.duplicates.CheckDuplicateClassesTask$_checkForDuplicateClasses_closure3.doCall$original(CheckDuplicateClassesTask.groovy:71)
        at net.idlestate.gradle.duplicates.CheckDuplicateClassesTask$_checkForDuplicateClasses_closure3.doCall(CheckDuplicateClassesTask.groovy)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at jdk.proxy2/jdk.proxy2.$Proxy155.apply(Unknown Source)
        at java_util_stream_Stream$collect.call(Unknown Source)
        at net.idlestate.gradle.duplicates.CheckDuplicateClassesTask.checkForDuplicateClasses(CheckDuplicateClassesTask.groovy:70)
The offending line of code can be seen here: CheckDuplicateClassesTask.groovy#L71 What's odd is that 
DefaultFileCollectionFactory.ResolvingFileCollection
does not implement 
org.gradle.api.artifacts.Configuration
. If it did it would also implement 
org.gradle.api.Named
and so would have a property 
name
. If I disable the configuration cache all is good. So presumably enabling the configuration cache somehow provides a 
DefaultFileCollectionFactory.ResolvingFileCollection
to the task instead of a 
org.gradle.api.artifacts.Configuration
which seems really unexpected...
v
Not really. Groovy is duck-typed. So if it quacks like a duck, it is a duck. And if it responds to the methods a 
Configuration
has, it is a 
Configuration
. So even if 
it
does not formally declare that it is 
Configuration
or 
Named
, as long as it responds to the 
name
property, it can be used. Without the CC, it probably directly is a 
Configuration
and thus 
name
works. With CC the configuration is serialized as 
FileCollection
and then deserialized as 
FileCollection
which then no longer responds to 
name
.
r
I don't understand why they chose to serialize 
Configuration
to something that did not contain a 
getName
? It seems a very small bit of extra data to serialize, and 
Named
a pretty fundamental interface to throw away.
Short of changing the plugin, is there anyway to alter the behavior?
v
Configuration has much more additional than just 
Named
. And it is not that they "serialize 
Configuration
as something else". If you for example have a 
Property<Configuration>
, CC will yell at you that 
Configuration
is not CC-compatible. But a 
Configuration
also implements 
FileCollection
. So if you have a 
Property<FileCollection>
(of course you would normally use a 
ConfigurableFileCollection
where you set 
from
on, just to explain the technical part), then you can set it to a 
Configuration
instance. But you declared you need a 
FileCollection
and that is what is serialized and deserialized. Using 
name
although you declared that you take any 
FileCollection
is like casting to 
Configuration
and getting 
name
or using reflection to get 
name
. You can do that in any JVM language and by just using 
name
in Groovy you basically do the same. But it will only work if the 
FileCollection
really is a 
Configuration
instance. If you put in any other 
FileCollection
, including a the deserialized one from the CC entry, it fails due to reflection not finding the method or the cast not succeeding or the respective property not found in Groovy.
And no, I don't think there is a way to fix it without changing or monkey-patching the plugin or not using CC. Even declaring the task as "not compatible with CC" will not work iirc.
r
But you declared you need a 
FileCollection
When?
v
I didn't analyze that plugin's code, but that is what matches the behavior you described. 🙂
Hm, from a quick look it seems that task takes indeed `Configuration`s, but then CC serialization should already fail
Unless of course you degraded CC errors to warnings with the command switch or Gradle property
r
I don't think so... I'll check
v
If that is the case, that would also explain the behavior. As that switch is meant to fix mutliple issues at once, but not for production use and often also causes such things as by degrading the error to warnings the problem still persists.
If that is not the case, I guess an MCVE could bring some clarity
r
Open in Slack
PreviousNext
Powered by