Migration of the build system and scripts from Gradle 6.8.3 to 7

[JinwooHwang]

As part of our modernization initiative, we have completed the migration of our build system and automation scripts from Gradle version 6.8.3 to version 7. This marks the initial phase of a broader effort to modernize our development infrastructure, including the Java and the Spring framework. This upgrade is expected to enhance the resilience and efficiency of our development pipeline while ensuring alignment with evolving industry standards.

Build & Gradle Wrapper

• Upgraded Gradle wrapper from 6.8.3 to 7.0 (gradle-wrapper.properties) to begin migration toward newer Gradle APIs.

Settings & Composite Builds

• Reordered settings.gradle: separated pluginManagement and plugins blocks; moved includes for annotation processor and scripts earlier; retained custom included builds (repeat-test, build-tools, testing-isolation) with dependency substitution.
• Added scripts composite build; ensures shared Gradle script plugins resolved as included builds.
• Preserved legacy Gradle version guard (GradleVersion check).

Internal API / Compatibility Fix

• Updated import in LauncherProxyWorkerProcessFactory to new package org.gradle.api.internal.file.temp.TemporaryFileProvider (internal package path change across Gradle versions).

Script Plugin Adjustments (build-tools/scripts)

• Added explicit Maven dependencies (maven-core, maven-model) to scripts build for plugins needing Maven model parsing.

Java Convention Script (geode-java.gradle)

• Replaced deprecated testCompile with testImplementation in custom testOutput configuration inheritance.
• Corrected artifacts DSL syntax: testOutput (jarTest).
• Fixed javadoc classpath to use compileClasspath instead of compileOnly (ensures full resolution).
• Minor formatting / parentheses normalization.

Publishing Logic (geode-publish-artifacts.gradle)

• Rewrote optional dependency collection: now aggregates from api, implementation, compileOnly, runtimeOnly, plus runtimeClasspath dependencies instead of legacy compile/runtime configurations removed in Gradle 7.
• Broader and future‑proof detection of optional deps for generated POM.

Root Build Script

• Refactored combineReports configuration: materialized task lookup into variable (cr), gathered all Test tasks once, added dependsOn for proper execution order.

Assembly Module (geode-assembly)

• Added outputs.dir to downloadWebServers for task output declaration (up-to-date checks).
• Introduced explicit dependsOn wiring from processDistributedTestResources to downloadWebServers to eliminate implicit dependency warning.

Connectors Module (geode-connectors)

• Declared inputs.files and outputs.dir for downloadJdbcJars for incremental correctness.
• Added dependsOn linkage from processDistributedTestResources to downloadJdbcJars to avoid implicit dependency warning.

Core Module (geode-core)

• Added duplicatesStrategy = EXCLUDE for processIntegrationTestResources to prevent duplicate resource conflicts during integration test resource processing.

General Task & Incremental Build Hygiene

• Multiple tasks now declare outputs.dir / inputs to leverage incremental builds and avoid Gradle warnings about implicit dependencies or undeclared outputs.

Optional / Runtime Dependency Mapping Modernization

• Transitioned away from deprecated compile/runtime configurations toward configuration names aligned with Gradle 7 (api, implementation, runtimeOnly, compileOnly, runtimeClasspath).

Test Aggregation

• Improved reliability of aggregated test reporting by explicitly making the combined report task dependent on all discovered Test tasks.

Net Effect

• Moves project onto Gradle 7 API surface (config name updates, import adjustments).
• Reduces deprecation pressure ahead of later Gradle upgrades.
• Improves correctness of publishing metadata (optional flags) and build reproducibility (declared inputs/outputs & task wiring).
• Cleans up resource processing and reduces warnings about implicit dependencies and duplicate resources.

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?