Make Gradle evaluation lazier and fix deprecation warnings#1826
Merged
Conversation
output of its own task, copied from shadowJar's archive via a tracked
input. shadowJar's pre-existing doLast block still did the same copy
itself, which was:
- redundant whenever both tasks ran, and
- an undeclared side effect of shadowJar, so it doesn't run on a
build-cache hit for shadowJar (only declared outputs are restored
on a cache hit; this doLast block would simply not execute).
assembleForJavac is now the only place that produces dist/checker.jar,
with proper inputs/outputs tracking. Nothing else in the build depends
on shadowJar alone to populate dist/; everything that needs dist/checker.jar
(exampleTests, demosTests, templateforaCheckerTests, etc.) already depends
on assembleForJavac.
pattern untouched: configuring a built-in task by its bare name (jar { },
test { }, javadoc { }, clean { }, compileJava { }, shadowJar { },
sourcesJar { }, generateGitProperties.dependsOn(...), etc.). That access
pattern realizes the task immediately when the build script line runs,
regardless of what was actually requested -- exactly what task
configuration avoidance is meant to prevent, and a needless cost on every
Gradle invocation across nearly every subproject.
Replace these with 'tasks.named("name") { ... }' (or a lazy
'dependsOn("taskName")' string reference instead of the task object)
everywhere a built-in task is configured directly by name:
build.gradle, checker/build.gradle, checker-qual/build.gradle,
framework/build.gradle, framework-test/build.gradle, and
framework-perf/build.gradle.
Not touched: checker/build.gradle's 'relocators = shadowJar.getRelocators()'
inside the checkerJar task registration. That's a genuine cross-task data
read (checkerJar needs shadowJar's already-configured relocators), already
inside a lazy 'tasks.register' block, and isn't a clean drop-in fix --
left as a known, lower-impact remaining case.
…ectly
at configuration time, but javacutil is declared after framework in
settings.gradle's include order, with nothing forcing javacutil's
build.gradle to evaluate first. That only works today because
javacutil/build.gradle never customizes its sourceSets (so the default
convention Gradle creates before any user script runs happens to be
correct); it's not something Gradle guarantees, and would silently break
if javacutil's sourceSets were ever customized.
Add evaluationDependsOn(':javacutil'), matching the existing guard
checker-qual-android/build.gradle already has for its own direct read of
checker-qual's sourceSets. dataflow doesn't need the same treatment here:
it's declared before framework already, so default evaluation order
already covers it.
This still leaves the underlying pattern (reading another project's
mutable sourceSets directly, rather than through a consumable
configuration or task-output Provider) in place; evaluationDependsOn
is the targeted, low-risk fix for the immediate ordering hazard, not a
replacement for that larger refactor.
configuration in between) by destinationDir.deleteDir() in the same task registration block, with nothing in between that reads or writes into the directory. Net effect is the directory doesn't exist either way before the Javadoc task itself runs and creates it as needed -- the pair is dead code, not a deliberate 'create then clean' step. Removing both has no behavioral effect.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.