JinwooHwang opened a new pull request, #7925: URL: https://github.com/apache/geode/pull/7925
## Summary This pull request removes a cross-project configuration resolution in geode-java.gradle that was triggering Gradle warnings of the form: ``` Resolution of the configuration :geode-unsafe:runtimeClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. ``` ## Key Change File: geode-java.gradle Replaced this block (removed): - Retrieval of ResolutionResult from geodeProject.configurations.runtimeClasspath - Iteration over resolutionResult.allComponents to derive upstream dependency JAR names With: - Metadata-only iteration over the already collected declared (first-level) runtime dependencies (depMap) - Construction of anticipated upstream JAR names using name-version.jar without forcing resolution ## Motivation Gradle 7+ warns—and Gradle 8 will fail—when a project resolves another project’s configurations during the configuration phase. This was producing noisy deprecation warnings during standard builds (e.g. :geode-core:jar) and risks breakage on future Gradle upgrades. Removing this eager resolution: - Reduces build noise - Moves us toward Gradle 8 compatibility - Keeps logic deterministic without unnecessary dependency graph traversal ## Testing & Validation Recommendations Run: ``` ./gradlew :geode-core:jar --warning-mode=all ``` Expected: - Prior runtimeClasspath cross-project resolution warnings no longer appear for this path. ## Performance Impact Slight build-time improvement: avoids constructing a full ResolutionResult for each upstream project during configuration of every Jar task. ## Behavior Before vs After |Aspect |Before |After |---|:---:|:---:| How upstream runtime deps were derived |Fully resolved incoming artifacts (ResolutionResult) of upstream project |Uses declared first-level dependency metadata already collected Cross-project configuration resolution |Yes (unsafe) |No Impact on generated Class-Path manifest entries |Functionally equivalent for first-level external deps; excludes any transitive-only jars that were previously (indirectly) included via resolved component graph ## Why This Is Safe The original logic only retained jars whose moduleVersion.id.name matched a declared dependency name captured in depMap. That effectively filtered the resolved component list back to the declared (first-level) external dependencies. Therefore the new approach—deriving jar names from declared dependencies—produces the same intended set for subtraction (upstreamDeps). Transitive-only artifacts (not directly declared) were not relied upon in the filtering logic. <!-- Thank you for submitting a contribution to Apache Geode. --> <!-- In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: --> ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [x] Is your initial contribution a single, squashed commit? - [x] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? <!-- Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to [email protected]. --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
