Modernization, Phase 3: Lazy property access via Provider API and findProperty#291
Merged
OdysseusLives merged 6 commits intomainfrom Feb 6, 2026
Merged
Modernization, Phase 3: Lazy property access via Provider API and findProperty#291OdysseusLives merged 6 commits intomainfrom
OdysseusLives merged 6 commits intomainfrom
Conversation
Replace eager property access with lazy Provider API: - lockAfterEvaluating: Use gradleProperty().orElse(extension) - updateDependencies: Use gradleProperty().map().orElse(extension) - overrideFile and override: Use gradleProperty().isPresent checks Benefits: - Lazy evaluation improves performance - Gradle properties properly override extension - Foundation for configuration cache compatibility
…nfigurer Replace hasProperty/property with findProperty() inside provider: - Maintains backward compatibility with both gradle properties and ext - Uses modern provider API for lazy evaluation - Cleaner than old conditional logic
Replace eager property access with lazy Provider API: - shouldLockAllConfigurations: Use gradleProperty().map().getOrElse() - additionalConfigurationsToLock: Use gradleProperty().map().getOrElse() Benefits: - Lazy evaluation during construction - Consistent Provider API usage across codebase - Foundation for configuration cache compatibility
…erty Replace eager hasProperty/property access with findProperty(): - readOverrides(): Use findProperty() for OVERRIDE_FILE - readOverrides(): Use findProperty() for dependencyLock.override Benefits: - Maintains backward compatibility with both gradle properties and ext - Cleaner than hasProperty/property pattern - readOverrides() is called during configuration phase from Plugin.apply()
…pt properties Eliminate project.hasProperty/property calls by refactoring: - Remove project and extension parameters from validate() - Accept three boolean validation flags as direct parameters - Update DependencyLockPlugin to resolve properties using Provider API - Update all test calls to pass resolved boolean values Benefits: - No more eager property access during validation - Cleaner separation of concerns (caller resolves properties) - Validation logic is now pure and testable - Consistent with Provider API pattern
…findProperty Replace eager hasProperty/property access with findProperty(): - verifySuccessfulResolution(): Use findProperty() for CONFIGURATIONS_TO_EXCLUDE - unresolvedDependenciesShouldFailTheBuild(): Use findProperty() for fail flag Benefits: - Single API call instead of hasProperty() + property() - Null-safe by design (returns null vs throwing exception) - Checks both gradle properties (-P) and project extras (ext) - Modern Gradle API recommended approach
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
1 participant
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.
Purpose
Replace eager property access (
project.hasProperty(),project.property()) with Gradle’s lazy Provider API andfindProperty()so that:Breaking changes
UpdateDependenciesValidator.validate()no longer accepts project and extension; it now takes three boolean arguments. Only the plugin and tests call this; both were updated. Any other internal or third-party code that calledvalidate(project, extension)must switch to the new signature and pass the resolved booleans.