Satyarth Sampath
07/19/2022, 2:42 PMCristianGM
07/20/2022, 9:36 AMversion
is a string, not a property, so as we use our CI build number (it's an env var) we can't do anything. In this case I think MavenPublication should allow us to use Properties so it's only read in execution time.CristianGM
07/20/2022, 9:38 AMVladimir Sitnikov
07/13/2022, 2:37 PMPaul Woitaschek
07/26/2022, 5:22 AMtwisterrob
08/17/2022, 8:21 AMval task1: VariantTask? = project.findTaskFor(variant, Task1::class.java)
val task2: VariantTask? = project.findTaskFor(variant, Task2::class.java)
val task = task1 ?: task2
if (task != null) { task.dependsOn(someOtherTask) }
and the definition of the utility
private fun <T : VariantTask> Project.findTaskFor(variant: String, taskClass: Class<T>): T? =
this
.tasks
.withType(taskClass)
.matching { it.variantName == variant }
.singleOrNull()
The problem is two-fold as I see it:
• find a way to do matching
without creating the tasks
• find a way to do ?:
on Provider<Task>
or another way to deal with no matching tasks for variant
Please 🧵 with any response.twisterrob
08/21/2022, 5:59 PMproject.tasks.configureEach { created.add(it) }
and then invoke gradlew :help
.Łukasz Wasylkowski
10/14/2022, 10:38 AM./gradlew <anyTask> --dry-run
should never create a single Task
instance during configuration phase, and if it does — that’s a place for improvement/fix? Even if the fix is not possible for some reason, no tasks created would be ideal, right?CristianGM
10/24/2022, 4:30 PMtasks.withType(X)
currently I can use TaskCollection.getNames()
but that's not a live/lazy collection, so I need to wrap it in an afterEvaluate
, I would say having names
as a live collection, would be great. I want to know about the tasks, not to realize them all.
Another approach would be using something like whenTaskAdded
, but currently it would realize all tasks too.
Any ideas? maybe a live collection version of names could be addedVampire
10/26/2022, 1:31 PMtasks.findByPath(':foo:bar')
cause all tasks of foo
to be realized? o_O
I see task :foo:baz
to be realized and configured although it is `register`ed, nowhere depended on, and also not triggered by command line.Łukasz Wasylkowski
02/07/2023, 7:24 PMtaskProp: Property<Boolean>
in a task based on a property passed via -P<prop>
? I can just do val value = roperties["prop"]
and taskProp.set(value)
but I’m wondering if there’s a way to map the prop
in a more reactive way and read the prop
as a Property
itselfVampire
03/23/2023, 6:44 PM:clean
task is realized during configuration always as soon as the lifecycle-base
plugin is applied?
And that it cannot be identified in the build scan.
There it only says one task was created during configuration but not which or where.
org.gradle.internal.tasks.stats
unveiled which task it is.twisterrob
04/07/2023, 1:18 PMproject.objects.directoryProperty().fileValue(File(string)).get()
but it feels weird to use project.objects.directoryProperty()
as a factory in this context, is there a better way?Vampire
08/04/2023, 9:54 AMtasks.matching { it.name == "check" }.configureEach { println("configure task matching name check") }
tasks.named("check") { println("configure check") }
not causing all tasks to be realized?
https://docs.gradle.org/current/userguide/task_configuration_avoidance.html says it is evil and realizes all tasks.Marek
08/18/2023, 3:10 PMRuleSource
something that can be used nowadays? Is it compatible with config avoidance? I have a plugin that Inherits from RuleSource
and creates some tasks. There are also other tasks that depends on the ones created by RuleSource
based plugin. However they use eager task API. when I try make them lazy the tasks created by RuleSource seem not to exist yet when the now lazy registered tasks are configured. I wonder if this is something that can be fixed or should I rewrite the plugin to not use RuleSource. I found that link that says RuleSource will become deprecated https://docs.gradle.org/current/userguide/rule_source.html