https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
t
You should probably configure your copy task to take the `licenseReportTask`'s outputs, rather than redeclaring something equivalent. That said, if it's 
com.jaredsburrows.license
, all tasks declare the same 
@OutputDirectory
by default, so you should probably start by using a separate output directory for each task.
v
I think you correctly identified the problem. That's one of the problems with tasks sharing outputs and with configuring paths instead of wiring outputs to inputs. I'm not familiar with Android builds. If the 
licenseReportTask
properly declares its ouptput to be the exact files and not declare the whole directory as output directory, then use 
from(licenseReportTas)
instead of the dir with filter and it should work properly I guess. Btw. are you aware that you completely disable task configuration avoidance?
By using 
tasks.matching
each and every task needs to be realized to check the predicate. If possible you should at least guard it before with a 
withType
to at least only force realization of all tasks of that type.
t
…though in this case 
tasks.named("license${variantName}Report")
should be enough (and then 
licenseReportTask.configure { … }
rather than then 
configureEach
). Same for the merge task: 
tasks.named("merge${variantName}Report") { dependsOn(…) }
.
t
OK, thank you! I’ll fix the configuration avoidance issue and create an upstream bug report for the output (IIRC I already did so, in https://github.com/jaredsburrows/gradle-license-plugin/issues/226, guess I comment why the default output structure this task uses is a bad idea even more)
v
though in this case 
tasks.named("license${variantName}Report")
should be enough
If the tasks are already registered, yes. I mean to remember that AGP does dirty stuff with registering tasks in 
afterEvaluate
or something like that. But that might also have changed in the meantime. I don't follow Android development too closely.
t
Yes, 
onVariants
is already better than 
afterEvaluate
, but I’ll try my best.
Hrm… 
tasks.named("…")
does not work, because the task is generated lazily afterwards and I can’t filter the task collection more, because the task’s type is 
internal
, i.e. not visible for me. (On a related note, I see this in more and more plugins that task classes are considered “private”, unaccessible for users, e.g. also in some of Jetbrain’s plugins, like 
kotlinx-kover
https://github.com/Kotlin/kotlinx-kover/blob/main/kover-gradle-plugin/src/main/kotlin/kotlinx/kover/gradle/plugin/tasks/reports/KoverHtmlTask.kt, is this actually bad design then, because there is no single task-matching lazy API available other than 
tasks.matching { … }
?)
Same issue with the Merge…Assets task.
v
Yeah, exactly the AGP fun I mentioned above. What you actually need is a fix for / implementation of https://github.com/gradle/gradle/issues/16543 to be able to get and configure a task provider for a task that might be added later on. But yeah, private task classes are not necessarily a good idea as you can then not get tasks by type. And even if you get the task by name, you would not be able to configure it if the task type is private. If they have some public task type for getting the tasks by type and configure them, but have a more specific private task type that adds internal stuff, that might be ok.
Btw. in the meantime this idiom is better:
Copy code
tasks.configureEach {
    if (it.name == "merge${variantName}Assets") {
        dependsOn(licenseReportTask)
        dependsOn(copyTask)
    }
}
👍 1
This way the task-configuration avoidance is not broken and the 
if
even needs to only be evaluated on the tasks actually being configure instead of all tasks.
t
Thank you!
👌 1
2 Views
Open in Slack
PreviousNext
Powered by