https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
A shared build service is the idiomatic pattern to aggregate results across a build. Sharing state between tasks is a code smell.
c
Maybe this is important to know: Not only do I want to aggregate across task but also across projects. Would a shared build service still work in that case?
Nvm, this is actually documented. But just to be clear: I do not want to access other Task instances from my aggregation task. In my scenario, many tasks create many files. And the only thing the aggregation task does is combine them. I control all the file formats. In this case, would you still suggest a build service? Just asking because I've never heard of this pattern and I am also unable to find where the docs would suggest that
t
How is the task disabled? seems to me that if the task is disabled its output directory should not be included with your aggregate tasks input collection and all would be well
if the inputs to your aggregate task didn't change I would say it is working as expected
c
Not sure what you are asking, so I'll try to further describe my issue. Maybe this clarifies stuff for you: I am creating a Gradle Plugin. This plugin is creating multiple analysis tasks that do analysis on Configurations. Each task is writing its results in a file. I also create a task that is aggregating these results. This aggregation task has a ConfigurableFileCollection as an Input that has all those analysis task declared as 
from
. This all works fine. But if one of the analysis tasks is disabled in the build script (e.g. via 
tasks.get("analysis").enabled = false
), then I still have the tasks output in my file collection. But this output is now old and therefore useless/misleading. Instead, I'd want the output file to disappear from my file collection. Does this make things more clear?
t
yes. so you are in the "working as expected" because even though your disabled task doesn't run, it still has an output that is being included as an input to your aggregate task
to do what you are wanting you might add a custom property to your task rather than the built in 
enabled
then in your task action: 
if(!customEnabled) //delete outputs else // do work
c
Hmm but for example the Jar task also shouldn't run on outdated class files, if "compileJava" was disabled, right?
Ah yeah! That workaround would work for me 🙂
t
I understand what you are saying. I just am not aware of if a disabled task should be actively removing its outputs from previous runs. its just that a disabled task still has to be fully configured to know if it is disabled or not
c
Yeah, I understand 🙂 Thanks for your help 🙂
💯 1
3 Views
Open in Slack
PreviousNext
Powered by