This message was deleted.
# community-support
s
This message was deleted.
v
To start with it would be great if Gradle were consistent. Annotation processor e.g. use a different dir than the Antlr plugin.
1
a
I tend to use the task’s temporaryDir, which is less likely to clash with other directories, and then don’t reference the output directory directly: instead reference the task’s output directory (example) I half-remember seeing some sort of discussion about providing a service for creating temporary files (possibly based on the internal TemporaryFileProvider ?). But I can’t find it, and I don’t know whether the purpose was for one-off temporary directories, or more stable directories where the specific location doesn’t matter, but can be managed by Gradle so as not to clash with other dirs There’s SourceDirectorySet, which is supposed to be a language-independent way of describing a set of files, but it’s pretty limited. There’s been some talk improving how to define sources used by an abstract language https://github.com/gradle/gradle/issues/727, because SourceSet is very Java focused
a
There is no convention unfortunately. I think in most cases it make sense that you namespace your output, e.g. with task name:
build/<task-name>/
, but in some cases that is harder if task name is very generic. But generally a good advice is: don't put outputs to a shared/common folders since that won't work ok with up-to-date checks. I believe we won't go in the direction of some constants, since that will probably mean, users will put outputs for a lot of tasks to the same folder and that doesn't work well with up-to-date checks. We have some ideas that Gradle would automatically assign output location and user would need to wire outputs of one task to another input via a property, something like Adam mentioned (and what is actually a proper way). Or at least have an annotation that would mean that Gradle should automatically assign an output. But there is nothing more than ideas at the moment for such feature and we don't have any actual plans for it.
e
So something like
build/generated/<my namespace>
would be ok but
/build/generated
would not?
v
Depends on the details. If you have specific output files, it is quite irrelevant where they are, as long as they are not within the output directory of another task. If you define the whole directory as output directory, then it is ok as long as no other task in your build writes anything to that directory, which could quite easily happen with such a generic name though. So even if you use
build/generated/<your namespace>
but then apply some plugin which thinks it is a good idea to define the whole
build/generated
as output directory, you are in trouble again.
The most important point is, that no two tasks should have overlapping outputs or modify the outputs of other tasks in-place.
👍 1
e
I recently encountered something interesting where an AGP API that depends on the output of a task seems to be moving the output to a new location.
v
Well, that is in the bad category if you really meant moving, not copying
e
I haven't looked through their code yet, but I'm assuming that's what it is. I was going crazy looking for the output I specified until I realized that the file was in this other directory.