https://gradle.com/ logo
Join Slack
Powered by
Hi there I have a quick question: do you know if t...
# community-support
j
Hi there I have a quick question: do you know if there was a change in the way 
@CompileClasspath
works in a task) between Gradle 8.1 and 8.2 ? I have a plugin with a different behavior between Gradle 8.1 and 8.2.
v
Mind elaborating on what difference you see? I very much doubt there is a behaviour change and if so, then most probably unintentional.
j
For the context, I identified a behavior change on https://github.com/palantir/gradle-revapi between gradle 8.1 and 8.2. With gradle 8.1, all works fine. I upgraded to gradle 8.2, and I see a behavior change: 1. With gradle 8.1, on https://github.com/palantir/gradle-revapi/blob/develop/src/main/java/com/palantir/gradle/revapi/RevapiAnalyzeTask.java#L103 the old version is correct with gradle 8.1, but the old version == new version with gradle 8.2 2. 
oldApi
is populated via https://github.com/palantir/gradle-revapi/blob/develop/src/main/java/com/palantir/gradle/revapi/RevapiAnalyzeTask.java#L84 (
@CompileClasspath
) I'm investigating with remote debugging, but I was wondering if 
@CompileClasspath
has somehow changed between gradle 8.1 and 8.2
v
But in which way is that related to 
@CompileClasspath
? The annotation does not influence the property's value. Just how it is interpreted and normalized when it comes to up-to-date checks and cache key calculation.
Besides that the type of that property is questionable anyway. Should probably better be 
ConfigurableFileCollection
instead of 
Property<FileCollection>
.
So the question most probably more is what you stuff into that property.
j
Ah yes, you are right about the proporty, it's basically the list of artifacts to compare with
the 
@CompileClasspath
confused me
👌 1
let me try to use 
ConfigurableFileCollection
to see if it helps
right, it's using `
Copy code
private final Property<FileCollection> oldApiJars =
        getProject().getObjects().property(FileCollection.class);
so using project proprty to get the 
Property<FileCollection>
v
Which actually is unnecessary boilerplate unless you need to support very ancient Gradle versions. As long as you let Gradle instantiate the task, you could just make the class and getter abstract and Gradle would care about the implementation
j
ok (NB: I'm not the original author of the revapi plugin, I want to fix the plugin in order to work with Gradle 8.2+ 🙂 )
do you mean I can make the 
RevapiAnalyzeTask
class abstract and remove 
oldApiJars
field (and corresponding setter) to let gradle inject the property ?
v
there is no setter. you have the field and the getter. and yes, if you remove the field and make the getter and class abstract, Gradle will accordingly implement the method as needed to work properly.
j
it sounds good thanks
👌 1
v
Same for all the other managed types, so the same for all 
RegularFileProperty
, 
Property<...>
, 
ConfigurableFileCollection
, and so on
j
ack
v
You can do it manually, but it is just unnecessary boiler-plate that Gradle can do for you
j
specifically about the behavior, I'm checking if the problem is not around 
ResolveOldApi
doing a remote debug with gradle 8.1 and 8.2 to compare the values in this class
FYI, I think I found the root cause of the behavior gap: the behavior change is coming from 
configuration.resolve()
. Here's the difference: • with Gradle 8.1, the configuration is a 
DefaultConfiguration
, using a 
resolver
which is 
ErrorHandlingConfigurationResolver
, with 
delegate
to 
ShortCircuitEmptyConfigurationResolver
• with Gradle 8.8, the configuration is a 
DefaultUnlockedConfiguration
. using a 
resolver
which is 
ShortCircuitEmptyConfigurationResolver
, with 
delegate
to 
DefaultConfigurationResolver
v
And this causes which change why?
j
with Gradle 8.1, it takes the "old" artifact, whereas with Gradle 8.8 it takes the "new" artifact
v
But why should a refactoring in the configuration and resolver classes influence what is going to be resolved?
j
let me share the piece of code where I'm seeing the problem
using 
project.getConfigurations().create()
I see a difference (using remote debugging) in the configuration created depending if I use Gradle 8.1 or 8.8
I guess that's why the 
configuration.resolve()
doesn't return the same result (depending of the gradle version)
I didn't do a 
git bisect
between gradle 8.1 and 8.2 to identify the change in cause
v
As I said, that you see a difference in the created configuration is expected as they do refactorings in that area. But it should not change behavior. If it does, you might have found an unintentional breaking change.
j
possible, let me do a 
git bisect
maybe it's around the 
ResolutionStrategy
by default (in 
configuration
)
2 Views
Open in Slack
PreviousNext
Powered by