The following is natural but doesn’t work because the ‘classes’ lifecycle task has no outputs:
jar {
from project(":other").classes
}
If lifecycle tasks were a first-class concept in Gradle, this could be made to work nicely.
I’m not sure when you would want to use this.
What use case do you have in mind?
You mean this particular example? Embedding the classes of another project in a Jar can be useful (e.g. to only have to ship a single Jar), and above code seems like a natural way to declare it. As a more general answer, it’s hard for users to understand that ‘compileJava’ does have outputs but ‘classes’ doesn’t.
It would mean that lifecycle tasks would need knowledge of their “children” though. For example, how do you know what .classes means for all the dependent tasks of ‘classes’?
What might be doable is for lifecycle tasks to expose their dependents…
task allClassFiles(type: Zip) {
from classes.dependents.withType(Compile)
}
But it’s debatable how much better that is than:
task allClassFiles(type: Zip) {
from tasks.withType(Compile)
}
Not identical by any means, but I wonder which one would be more common.
It would mean that lifecycle tasks would need knowledge of their “children” though.
Well, Gradle already knows about task dependencies. But since we don’t want this behavior for “regular” tasks, it would have to know which tasks are lifecycle tasks.
Not identical by any means, but I wonder which one would be more common.
‘classes’ seems like the obvious choice to refer to the entire compile output of a source set (including resources). My real point though is that it seems generally useful to define the outputs of a lifecycle task as the outputs of its nearest “regular” task dependencies.
Just “forwarding” the outputs makes sense I guess.
We don’t really need any more model elements to do this now I don’t think, just a little bit of extra wiring when creating tasks like ‘classes’.