https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Changing the configuration of a task during its own execution phase is even worse than changing the configuration of a task from the execution phase of another task. So no, this is not the correct approach. You for example disturb up-to-date checks and if it were cacheable also cache entries. A valid approach would be (as ad-hoc version)
Copy code
val generateManifest by tasks.registering {
    val outputFile = layout.buildDirectory.file("MANIFEST-generated.MF")
    outputs.file(outputFile).withPropertyName("generatedManifest")
    doLast {
        outputFile.get().asFile.writeText(
            """
                Foo: bar
            """.trimIndent()
        )
    }
}

tasks.jar {
    dependsOn(generateManifest)
    manifest {
        from(generateManifest.map { files(it).singleFile })
    }
}
Or as proper task class version:
Copy code
abstract class GenerateManifest : DefaultTask() {
    @get:OutputFile
    abstract val generatedManifest: RegularFileProperty

    @TaskAction
    fun taskAction() {
        generatedManifest.get().asFile.writeText(
            """
                Foo: bar
            """.trimIndent()
        )
    }
}

val generateManifest by tasks.registering(GenerateManifest::class) {
    generatedManifest.set(layout.buildDirectory.file("MANIFEST-generated.MF"))
}

tasks.jar {
    dependsOn(generateManifest)
    manifest {
        from(generateManifest.flatMap { it.generatedManifest })
    }
}
Unfortunatley, it needs an explicit 
dependsOn
as the implicit task dependency is not respected in this case. I just reported that as https://github.com/gradle/gradle/issues/25435
t
What a savior you are 🙂
Copy code
manifest {
    from(generateManifest.flatMap { it.generatedManifest })
}
Is nice. I didn't know about it. Thank you for your help! Side note: my 
GenerateManifest
task actually uses a Build Service's properties (which can not atc as an task input at the monent) so I can not reuse the task's output. So UP-TO-DATE check doesn't bother me right now.
👌 1
v
which can not atc as an task input at the monent
who says that?
This works perfectly fine for example:
Copy code
abstract class RandomService : BuildService<BuildServiceParameters.None> {
    val randomValue get() = Random.nextInt()
}

abstract class RandomTask : DefaultTask() {
    @get:ServiceReference
    abstract val randomService: Property<RandomService>

    @get:Input
    abstract val input: Property<Int>

    init {
        input.set(randomService.map { it.randomValue })
        outputs.upToDateWhen { true }
    }

    @TaskAction
    fun taskAction() {
        println(input.get())
    }
}

gradle.sharedServices.registerIfAbsent("random", RandomService::class) { }

val random by tasks.registering(RandomTask::class)
The task 
random
it out-of-date because the input changes. And if you change the build service to always return the same value, the task is properly up-to-date.
t
who says that?
Well, the documentation says: Note that using a service with any other annotation is currently not supported. For example, it is currently not possible to mark a service as an input to a task. But your approach:
Copy code
init {
    input.set(randomService.map { it.randomValue })
    outputs.upToDateWhen { true }
}
looks promising. I didn't know that I can do it like that. I will try that. Thank you!!
👌 1
3 Views
Open in Slack
PreviousNext
Powered by