Express compile classpath as a FileCollection, propagating dependencies #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
Module.compileClasspath
is aCollection<File>
. This works for holding the set of files in the classpath. However, Gradle stores information about how those files are generated in aFileCollection
, which is generally how plugins expose compile classpaths. When a task depends on aFileCollection
, these generation dependencies are propagated to the task. Without those dependencies, the task won't generate those files as needed, which causes #9.This changes
Module.compileClasspath
to be aFileCollection
, and adds it as an input to the signature generation task. As a result, tasks that generate code for the compile classpath will be run when runningmetalavaGenerateSignature
, which is desired.Side note: I agree with many of the changes in #28, which has some overlap with this change. This is a smaller fix that also addresses the first issue described in that PR.