https://gradle.com/ logo
Join Slack
Powered by
Hey everyone! Do you know if there’s anything simi...
# plugin-development
f
Hey everyone! Do you know if there’s anything similar to 
@SkipWhenEmpty
for a single file? I’d like to configure the input of a task in such a way that the task is skipped if: • The file doesn’t exist. • The input is set with a 
provider { null }
. I think this PR asks for something similar, but I couldn’t make it work with a file collection.
I tried this:
Copy code
@get:Optional
@get:InputFiles
@get:PathSensitive(PathSensitivity.NONE)
val sourcemap: RegularFileProperty = objectFactory.fileProperty()
and this:
Copy code
@get:InputFiles
@get:SkipWhenEmpty
val sourcemap: ConfigurableFileTree = objectFactory.fileTree()
but when setting the input like this:
Copy code
task.sourcemap.set(project.provider { null })
the task isn’t skipped.
I could always check the file on execution time, but it’d be nice if the task was just skipped
v
@Optional
means "do not file if there is not value set", not "skip if no value set". Replace 
@Optional
by 
@SkipWhenEmpty
and it works. (the latter implies the former) And maybe replace 
@InputFiles
by 
@InputFile
, it feels strange to have the plural on a singular property. I didn't even now that works.
👀 1
m
it’d be nice if the task was just skipped
Out of curiosity, is there anything to this besides a nicer log output? Like does it come with better performance or anything like this?
f
Like does it come with better performance or anything like this?
Probably not a big impact for just one task, but I’d like the tasks that depend on the skipped task to be skipped too.
I’ll test that, Vampire, thanks!!
👌 1
v
By default a task depending on the skipped task is not skipped though. You need to use 
onlyIf
on the depending task and for example check 
didWork
property on the skipped task. Just that you know
f
oh, so besides the cleaner log output there are no advantages compared to just checking the value at execution time?
m
That's my current understanding. And part of the reason why I'm not too big on this.
v
Well, imho cleaner output is a great reason to do it. 🙂 Performance gain is probably indeed only marginal if at all. Maybe it is also interesting for statistics or for other tools or tasks that track whehter the task did work / was skipped, ... 🤷‍♂️
➕ 1
m
I wish the API were a bit different, more like the problems API. Having this on inputs makes you believe there is some magic attached to it, while in practice, there is not really
3 Views
Open in Slack
PreviousNext
Powered by