Don't register output directory as a set of files, since this breaks Gradle 5.0+ #940
Conversation
In order for task caching to work, tasks have to define their inputs and outputs. These are defined as a set of files, directories, properties and such. Until Gradle 4.3 defining inputs was very lax - you could pass directories in place of files and vice versa. Starting with 4.3 there is a set of validators which check for this and issue a warning if at configuration time the declared type of file (directory/normal file) doesn't match the filesystem. Starting with 5.0, these warnings are now errors - while the task works just fine on the first build, subsequent ones discover that the output is a directory, while it's defined in two places as both a file and a directory = this fails the build at configuration time (even if the task is not ran). Removal of this line resolves #809 by removing that ambiguity. Tested on Gradle 2.3, 4.10.2, 5.0-rc-4.
...o-gradle-plugin/src/main/groovy/org/jsonschema2pojo/gradle/GenerateJsonSchemaJavaTask.groovy
Show resolved
Hide resolved
|
Agreed, writing some kind of test to verify this in different Gradle versions will involve a lot of gymnastics and not much future value, so I'm happy to merge this based on your exploratory testing. |
joelittlejohn
changed the title
|
Thanks! Do you plan on releasing any subsequent beta versions in the near future? I guess I'm not the only one who intends to upgrade to Gradle 5.0 soon after it gets released, and this issue is going to affect everyone with any sort of a multi-step build pipeline. |
|
My plan was to release 1.0.0 (GA) next. |
|
@joelittlejohn thanks. Do you have any plans as to when the release is going to take place? Even a guesstimate? |
|
@lared Lets do it very soon :) |
|
@joelittlejohn: do you happen to have updates on "very soon" :D? Sorry for being a pain in the ass. |
|
@lared It's done. Thanks for the reminder. |
In order for task caching to work, tasks have to define their inputs and
outputs. These are defined as a set of files, directories, properties
and such.
Until Gradle 4.3 defining inputs was very lax - you could pass
directories in place of files and vice versa. Starting with 4.3
there is a set of validators which check for this and issue
a warning if at configuration time the declared type of file
(directory/normal file) doesn't match the filesystem.
Starting with 5.0, these warnings are now errors - while the task works
just fine on the first build, subsequent ones discover that the output
is a directory, while it's defined in two places as both a file and a
directory - this fails the build at configuration time (even if the task
is not ran).
Removal of this line resolves #809 by removing that ambiguity. Tested on
Gradle 2.3, 4.10.2, 5.0-rc-4.
@joelittlejohn Since that is a weird hooking-up-in-framework kind of a bug, would you recommend any tests to be also written? It seems like this is very unlikely to provide any sort of benefit in the future.