https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Whatever you will try. You must not change the configuration of another task (or own) at exexution time, no matter how you reference it, or it is CC incompatible, fullstop. 🙂
If that 3rd Party task needs a 
String
, you need to calculate that string at configuration time.
Even if it were a 
Property<String>
, it would be calculated at configuration time, as provider values of tasks are realized and written to configuration cache when storing the CC entry afair.
t
Interesting. I was expecting that all @Input @Output fields of task are not serialized and are handled just before execution. Because this is stuff that is not the same. I mean I will change source code in my project, configuration cache should be still without change, but compile task will have a different input.
Ah sorry I read it badly, you are talking about providers no content itself
v
Yes
t
But then it is OK, when 3rd party taks will have Property<String> I can simply do this, even without extra task
Copy code
3rdPartyTaskProvider.configure {
    inputText.set(project.providers.fileContents(xyz).getAstext())
}
If that 3rd Party task needs a 
String
, you need to calculate that string at configuration time.
And this is allowed? It basically depend just on the setup inside of build.gradle file. I mean this input string. So it can be serialized inside of configuration cache.
But disadvantage is that this task is called only for production builds, so currently it is called very rare. Filling it in configuration time mean, that it will be prepared every time.
v
Why? If you leverage task-configuration avoidance, it will just be done when the task is going to be executed
t
Ahh, inside 
configure {}
, yes this should work.
Thanks!
👌 1
It looks that it works. Why I was trying to do it in such complicated way, when it is so simple.
🤷‍♂️ 1
14 Views
Open in Slack
PreviousNext
Powered by