https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
a
probably not https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:disallowed_types
Referencing dependency resolution results is also disallowed (e.g. ArtifactResolutionQuery, ResolvedArtifact, ArtifactResult etc…​).
t
Those are requirements for things that will be serialized into the cache after configuration, I don't think there's any limitation at runtime.
👆 1
v
What remains, is to consider, that artifact resolution queries are discouraged.
They are not properly variant / attribute aware
Unfortunately there is not yet a proper replacement which is afaik the only reason they are not yet deprecated.
And of course, that 
getDependencyHandler()
is internal API. At least I only find it on internal classes.
If you get it from 
project
, i.e. 
project.dependencies.createArtifactResolutionQuery()....
, then we are back at not CC compliant as you must not access 
project
at execution time and I doutb that it is acceptable to have 
project.dependencies
as task property value either.
e
@Vampire I had already discovered the variant issue and this was the only way I could get it to work. I didn't include the full context, because that's available in the linked PR, but 
getDependencyHandler
is annotated with 
@Inject
in the task:
Copy code
public abstract class SpdxSbomTask extends DefaultTask {
  @Inject
  protected abstract DependencyHandler getDependencyHandler();

  ...
}
til 1
v
Oh, interesting, I was not aware you can inject it. But I'm also not sure whether that is supported. At least it is not documented as in injectable service.
this was the only way I could get it to work
Yeah, because it completely ignores attributes. So you might get "something", but maybe not the "right thing". 🙂
e
So far it seems to be correct for what I need it for. Just wanted to validate that there wasn't anything intrinsically wrong with doing that from Gradle's perspective.
v
From CC perspective I don't think so. Just that using ARQ at all is wrong as Gradle folks said, and that I'm not sure whether injecting the dependency handler is a supported action. 🙂
e
Can anyone from Gradle comment on the status of injecting a 
DependencyHandler
and using 
ArtifactResolutionQuery
?
j
I would recommend against using ARQ. The only reason this API is around is because it can resolve POMs and Ivy descriptor files, which Configurations cannot do. We really should clarify this in the docs.
Is there a reason you're using ARQ as opposed to a Configuration?
I see you are trying to read POMs. There is currently not a good CC-compatible story for this in Gradle currently. This is seemingly the relevant issue: https://github.com/gradle/gradle/issues/25589
e
I'm using it because a configuration can't be stored as a task input. I get a 
ResolvedComponentResult
from the configuration when configuring the task, and this is the only way I could get the POMs I need at task execution time. It seems to be working with CC though, at least I haven't noticed any issues.
I'm able to achieve what https://github.com/gradle/gradle/issues/25589 is looking to do without a detached configuration (as far as I can tell, unless that's happening under the hood of ARQ)
j
ARQ uses detached configurations under the hood
e
Well there it is then 😅
So until that issue is addressed this is the best way I could find to achieve what I need. Didn't seem to cause any CC issues though. Does CC get disabled automatically when using ARQ?
j
Does CC get disabled automatically when using ARQ?
I do not believe so
e
Interesting, because I run that task with CC enabled and everything works fine
j
It might be a corner case that CC is not handling properly. I am surprised that accessing the DependencyHandler works in the task action with CC enabled
I worry that this hole may be closed eventually. I’ll ping the CC guys and see if they can add more detail here
thank you 1
p
At licensee, we use a detached configuration with the variants set: https://github.com/cashapp/licensee/blob/trunk/src/main/kotlin/app/cash/licensee/task.kt#L149
e
Well then it looks like gradle has where to draw inspiration from when designing a better API 😅
v
I'm using it because a configuration can't be stored as a task input.
That's not fully correct. If you declare the property 
FileCollection
and set it to a configuration, it works fine.
➕ 1
e
Is that a recent change? I remember trying that a while ago and it didn't work
@Justin Van Dort did you ever hear back about this?
j
I recall asking them about the hole in CC but after trying to find the message I cannot find it. I just pinged them to see if they can chime in.
thank you 1
So in general we strongly discourage doing any sort of dependency resolution at execution time.
Would you be able to add an @Input to your task with some 
Property
, and then configure the value of that property with the result of your ARQ? That way, the ARQ is executed during serialization-time, in between configuration time and execution time
So something along the lines of
Copy code
abstract class MyTask {
    @Input
    abstract MapProperty<String, PomInfo> getPoms()
}

tasks.register("doStuff", MyTask) {
    poms = project.provider(() -> {
        // Do ARQ and effective POM calculations here
    })
}
v
Is that a recent change? I remember trying that a while ago and it didn't work
Sorry, missed that question. No, it is not a recent change. It was always like that.
e
@Justin Van Dort that's what I used to do, but I was under the impression that it was undesirable which is why I've been looking for a different way to do it 😅
j
That is our recommended approach for now. If it works for you I think that's your best bet
👍 1
2 Views
Open in Slack
PreviousNext
Powered by