https://gradle.com/ logo
Join Slack
Powered by
Giving kotlin a try, and I'm getting a really weir...
# community-support
r
Giving kotlin a try, and I'm getting a really weird error when trying to set file permissions in a CopySpec. The files exists.
Copy code
val commonDist = project.copySpec {
    from(layout.projectDirectory.dir("packageFiles/common")) {
        into("")
        filesMatching("test.cfg") {
            println(name)
            println("test")
            println(file.exists())
            filePermissions {
                user {
                    read = true
                    write = true
                }
                group {
                    read = true
                }
                other {
                    read = true
                }
            }
        }
    }
}
Copy code
1: Task failed with an exception.
-----------
* What went wrong:
Could not load the value of field `delegate` of `org.gradle.api.internal.file.copy.CopySpecWrapper_Decorated` bean found in field `$this_from` of `Build_gradle$commonDist$1$1$1` bean found in field `toApply` of `org.gradle.api.internal.file.copy.MatchingCopyAction` bean found in field `mainSpec` of task `:commonFiles` of type `org.gradle.api.tasks.Sync`.
> null cannot be cast to non-null type org.gradle.api.file.FileCollection
v
Please provide the full 
--stacktrace
, optimally as build 
--scan
URL, or maybe an MCVE.
r
here's the scan
v
That's a scan, but not the one with the error you mentioned
r
v
Also not. That is "DefaultCopySpec cannot be cast to class FileCollection". What you wrote above is "null cannot be cast to non-null type FileCollection".
r
that one should be the null issue
this copyspec is used in 
project.sync
as well as a few 
Sync
tasks
v
Do you use 
org.gradle.configuration-cache.problems=warn
or 
--configuration-cache-problems=warn
?
r
Copy code
org.gradle.configuration-cache=true
org.gradle.configuration-cache.parallel=true
org.gradle.warning.mode=all
org.gradle.configureondemand=true
v
You also get a configuration cache problem with the exact same task you have the problem with. Try to fix that and maybe that cast error is then just a follow-up error that vanishes alongside
r
you mean the one about the 
Thread
? I dond't have anything like that:
Copy code
tasks.register<Sync>("commonFiles") {
    with(commonDist)
    into(layout.buildDirectory.dir("commonFiles"))
}
v
Well, check the CC report where it is coming from
But yes, that is what I mean
r
so, if I comment out the filePermissions the CC error is resolved
v
Can you push your state to some branch?
r
v
And what did you run there to get that error?
r
the earliest task in the chain to reproduce it is 
commonFilles
v
But that gives the "The value for this property is final and cannot be changed any further" error, not the "null cannot be cast" error
r
if delete the build directory it gives the null error, I had been running with clean to check everything was working
v
Btw. 
filePermissions
within 
filesMatching
does not make much sense anyway. If you (just temporary for better ide clearness) add 
this.
in front of 
filePermissions
, or navigate to it with 
Ctrl+Click
, you see that it is not from the file copy details in the 
filesMatching
but from the copy spec.
And if I delete 
build/
, I still get the "final" error, not the "null" error
Also when doing 
gw clean commonFiles
r
delete it without syncing
v
I did
r
well, that was a mistake with the groovy version as well then
v
Quite possible
r
Changing it to 
permissions
seems to have fixed it, thanks. I didn't realize it worked that way
v
Ah, yes, 
permissions
was it in the 
filesMatching
, exactly.
Also moving the 
filePermissions
out of the 
filesMatching
at least solved the "final" error, probably also the "null" error, but of course would not be the semantic you intended.
r
thanks for the help!
👌 1
So in pushing it 🙃, I have somehow broken it when trying to run the package tasks, it was working but now the plugin is throwing an NPE saying the extension is null Configured via
Copy code
configure<PackagePluginExtension>
Plugin code to get the extension which appears null: 
PackagePluginExtension extension = getProject().getExtensions().findByType(PackagePluginExtension.class);
<https://gradle.com/s/jrotixbbri32g>
v
You should imho never set a duplicates strategy anywhere anyway. 🙂 If Gradle complains you need to set one, you should instead make sure no duplicates happen, as that is usually the base problem and the duplicates strategy is just symptom treatment and might even easily lead to unexpected or intended behavior. Having said that, if you du 
findByType
and get 
null
, that usually either means the extension was not registered yet, or the type does not match, for example if it it was registered with a class named 
PackagePluginExtension
from one class loader but looked up with a class named 
PackagePluginExtension
from a different class loader which makes them different classes even if their FQCN is the same. But hard to say from only a message or scan
r
not much I can do about the plugin using it, but this was working before which is why I am confused
v
I don't know what "before" and "now" is. If it is just 
filePermissions
to 
permissions
then it is unlikely this causes it. 🤷‍♂️
r
ok, so it was because I added 
org.gradle.configuration-cache.problems=warn
. Why does that break things?
v
Because you shouldn't use it 😄
It degrades CC errors to warnings. It is nice if you want to fix them in bunch and get more errors at once. But if there were errors, then most likely executing it anyway will result in very strange errors.
Back in older versions this was only the case on second run as the first run did not use the CC-entry state, but the freshly built state. But since some time it was changed so that even with the first run the CC entry is serialized, deserialized, and then that state used which makes strange failures with the warning-degrade even more likely but besides that cares for more reproducible and reliable builds.
r
I see I'm still testing CC locally (have been for a few months now), due to the versioning plugin being incompatible as well as the packaging tasks (we had spoken before when I was trying to make a PR to fix the usage of it generating zip tasks at runtime)
thanks again, I'll keep bashing my head with this
Open in Slack
PreviousNext
Powered by