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
itselfŁ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
02/07/2023, 7:47 PMproviders.gradleProperty
I guessŁukasz Wasylkowski
02/08/2023, 8:06 AMproviders
is what I missed, I was looking for top-level stuff 🙂
So I got
val ignoreFailuresProp = providers.gradleProperty("ktlint.ignoreFormatFailures").map { it.toBoolean() }.orElse(
true)
tasks.withType<FormatTask>().configureEach {
ignoreFailures.set(ignoreFailuresProp)
}
and I’m wondering if it’s in any way more appropriate or better than reading the property right away. I guess now it’s read lazily, what if there’s more than one FormatTask
in the project — will it be read more than once? I tried to follow implemention and docs but can’t tell for sureBut you should consider using proper `@Option`s instead.That would be on the task author, right? In my case it’s a 3rd party plugin
Except probably if you need to be able to set it via properties file.actually I do 😄 That’s a preference team members would set for themselves, having to pass it when running Gradle wouldn’t be ideal
Vampire
02/08/2023, 8:37 AMmap
for similar step the same.
But you can easily create a cached provider like
inline fun <reified T> cachedProvider(crossinline block: () -> T): Provider<T> =
objects
.property<T>()
.value(provider { block() })
.apply {
disallowChanges()
finalizeValueOnRead()
}
And then you can use it like val foo = cachedProvider { calculateComplexValue() }
Łukasz Wasylkowski
02/08/2023, 8:39 AMvalue(provider { block() })
or by disallowChanges(); finalizeValueOnRead();
? 🤔property
, not provider
👍 Looks like it’s not really worth it for a gradle property per se, but good to know how to achieve laziness in similar cases 🙂Vampire
02/08/2023, 8:41 AMdisallowChanges
effectively makes the Property
a Provider
or someone could downcast and call mutators.
finalizeValueOnRead
makes it calculate once and remember.provider { block() }
makes the value be calculated only on first readProvider
as input, but I liked it better that way, usage-wiseŁukasz Wasylkowski
02/08/2023, 11:19 AM