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

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.

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?

• Is your initial contribution a single, squashed commit?

• 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?