Spring boot project - being used to see if I can learn gradle by converting from an existing maven project.
As part of that - I have a set of files that are generated which I need to be included in the generated boot jar under BOOT-INF/classes/static. These are only relevant in the packaging stage - they are only read when the jar is deployed - not by anything like test/test coverage etc.
The simplest way I found on that was a generate task that generates the files then a dependent copy task that copies the generated files to build/resources/main/static
This works fine.
But it does trigger a lot of Reason: Task ':A' uses this output of task ':copyTask' without declaring an explicit or implicit dependency
In most cases - this is nice - I do need to state that anything involved in the packaging steps must depend on this copy task (in this case - bootJarMainClassName). So that makes sense.
However - it also complains that this is the case for test, jacocoTestReport and compileTestKotlin
Now - I could just make them depend on the same copy task - even though the files are only relevant in the packaged jar (nothing in test will read/use them).
BUT - the generation of the files is a long process - I would really like to avoid calling the task for every call to the test tasks.
Is there any way of saying “Btw - taskX - you can ignore these files when calculating if there is a missing dependency declaration” ?
To start with, your copy task is maaaajorly bad.
You should never have overlapping outputs for multiple tasks.
So having a task that copies things into the output direcotry of another task like you do is majorly bad and will cause a lot more trouble than you already got into.
If you only need these files at final runtime, configure the task that packages up the final artifact to include the result of the generate task. If you want those files be normal resources available everywhere resources are used, including test task, source jar task and so on, register it properly as resource directory like
sourceSets {
main {
resources {
srcDir(myGenerateTask)
}
}
}
which will use the outputs as resources and automatically add necessary task dependencies where needed.
You should basically never use explicit dependsOn statements except if on the left side is a lifecycle task. Almost all other cases are just a work-around instead of doing it properly, wiring task outputs as inptus for other tasks or extensions.
Sounds logical. This is what happens when you try to migrate from one build system to another Had a feeling that the problems with the depends stuff was a hint that the approach was wrong.
Not needed other than in the final jar - in fact - I don’t even want to trigger the generation until we get to building the final jar - so if I understood you - sourceSets sounds not quite the right match?
So - I need to look at the other bit - “configure the task that packages up the final artifact to include the result of the generate task”
That’s the bootJar from spring boot plugin - this seems to work:
This does feel a lot better from a logical point of view (I just had no idea that I could do this) - but - it still has the dependsOn clause to trigger the actual building of the contents. Not entirely sure if this is what you meant as “left side”. So - not sure if this is correct ?
Yes, each task should always properly declare its inputs and outputs.
Otherwise it can never be up-to-date, or used with the task output cache, or used as input for other tasks.
Had a feeling that the problems with the depends stuff was a hint that the approach was wrong.