Remove afterEvaluate wrapper v2 #4271
Merged
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.
v2 of #4159
The reason this didn't work on the first attempt is that
bootClasspath
on the Android Gradle Plugin'sBaseExtension
is aList<File>
and was being called during the configuration phase when it was empty. By wrapping in aprovider {}
call the parameter becomes live so the value will be queried at task execution instead, when it's been populated. cc @BraisGabin in case you want to confirm (I have successfully tested on a local Android project).I've also reversed the test behaviour change introduced in #4262 as the test no longer fails.
I still need to add a functional test for Android. I will do this once #4074 is merged.
Original PR description follows:
Removes usage of
afterEvaluate
in the Gradle plugin.This causes race conditions (evidenced by the double use of
afterEvaluate
in DetektMultiplatform class) and makes it more difficult for users to customise individual tasks created by the plugin.Generally
afterEvaluate
shouldn't be required when Gradle's lazy configuration and task configuration avoidance APIs are used. The only tests that failed when I removed it is the multiplatform Android tests, but switching to reactive DomainObjectContainer#all instead of DomainObjectContainer#forEach fixes that.If there are other use cases that require using
afterEvaluate
I'll investigate, and if the test coverage didn't pick up issues that removal will now cause, please let me know so I can address it.Would fix root issue raised in #3428