JinwooHwang opened a new pull request, #7927:
URL: https://github.com/apache/geode/pull/7927

   ## Summary
   
   This PR upgrades the Gradle Wrapper to **7.3.3**, unlocking:
   
   - Official **Java 17 (LTS)** toolchain support  
   - Compatibility groundwork for **Jakarta EE 9** (namespace transition: 
`javax` → `jakarta`)  
   - Modern build performance + richer diagnostics (configuration cache 
maturity, faster incremental builds)  
   
   This is a strategic platform upgrade that keeps Apache Geode aligned with 
current JVM and enterprise ecosystem evolution while minimizing disruption to 
existing contributors.
   
   ---
   
   ## Motivation
   
   - **Java 17 LTS Adoption**: Many downstream users and contributors are 
moving toward 17. Gradle ≤7.2 lacks full reliability with JDK 17 (notably 
around toolchains and `--release` handling).  
   - **Jakarta EE 9 Ecosystem Shift**: Libraries (e.g., servlet containers, 
security stacks) are increasingly publishing `jakarta-*` artifacts. Build 
tooling must be current to experiment safely with transitional modules.  
   - **Security & Maintenance**: Staying current reduces exposure to Gradle 
core or plugin issues already fixed in the 7.3.x line.  
   - **Developer Experience**: Faster configuration + improved task avoidance + 
better diagnostics in dependency resolution and variant selection.  
   
   ---
   
   ## Key Changes
   - Updated `gradle-wrapper.properties` to use `gradle-7.3.3-bin.zip`.  
   - Ensured build remains compatible with existing Java baseline while 
enabling optional Java 17 toolchains (future follow-up).  
   - Verified core and integration modules compile under Gradle 7.3.3 without 
deprecated configuration failures.  
   - Audited for removed legacy incubating flags (none blocking).  
   
   ---
   
   ## What This Does **NOT** Do (Yet)
   
   - ❌ Does not switch project baseline to Java 17 (runtime / production 
remains unchanged).  
   - ❌ Does not perform bulk `javax.*` → `jakarta.*` namespace migrations 
(future staged efforts).  
   - ❌ Does not enable configuration cache by default (can be evaluated 
incrementally).  
   
   ---
   
   ## Impact & Risk Assessment
   
   | Area                   | Impact       | Notes                              
                                   |
   
|------------------------|--------------|-----------------------------------------------------------------------|
   | Build Reproducibility | Low          | Wrapper pin ensures determinism.    
                                 |
   | Contributor Onboarding| Positive     | Modern JDKs usable out-of-the-box.  
                                 |
   | CI Pipelines          | Low          | Gradle command interface unchanged. 
                                 |
   | Plugins               | Low/Moderate | Any custom or internal plugins 
should be smoke-tested (already done).|
   | Downstream Extensions | Minimal      | Unless they depended on internal 
Gradle task wiring.                 |
   
   ---
   
   
   ## Testing Performed
   
   - ✅ Wrapper integrity check  
   - ✅ Full clean build  
   - ✅ Verified no new failing tasks due to removed internal APIs  
   - ✅ Ensured no extra unexpected dependency graph changes  
   
   ---
   
   
   ## Performance Observations (Expected)
   
   - ⚡ Slightly faster configuration phase (5–10% typical in large multiproject 
builds)  
   - ⚡ Improved parallelization heuristics for test tasks  
   - ⚡ Cleaner deprecation reporting (actionable for future 8.x prep)  
   
   ---
   
   ## Rollback Plan
   
   If unforeseen regressions occur:
   
   1. Revert this PR (restores previous wrapper + scripts)  
   2. Clear `~/.gradle/caches` if local anomalies persist  
   3. Open a follow-up issue documenting incompatibility for triage  
   
   ---
   
   ## Follow-Up Opportunities
   
   - Introduce Gradle toolchains block for explicit multi-JDK testing  
   - Begin Jakarta namespace migration in isolated modules (low-churn first)  
   - Evaluate enabling configuration cache & build scans in CI  
   - Add Java 17 tier to official compatibility matrix  
   - Audit custom plugins for Gradle 8 readiness  
   
   ---
   
   ## Related Tickets / References
   - [GEODE-10462](https://issues.apache.org/jira/browse/GEODE-10462)  
   - [Gradle 7.3.3 Release 
Notes](https://docs.gradle.org/7.3.3/release-notes.html)
   - [Jakarta EE 9 Migration Guide](https://jakarta.ee/release/9/)
    
   
   ---
   
   ## Reviewer Checklist
   
   - [x] Wrapper URL & distribution type are correct (`bin` vs `all` as 
intended)  
   - [x] No accidental file mode changes on `gradlew`  
   - [x] CI green across mandatory matrices  
   - [x] No new critical deprecation warnings  
   - [x] Sanity test of a module under JDK 17 passes  
   
   ---
   
   ## Contributor Tips
   
   If IDE complains post-upgrade:
   
   - **IntelliJ**: Re-import Gradle project  
   - **Eclipse**: Refresh Gradle project / regenerate metadata  
   - Clear stale Gradle daemon:  
     ```bash
     ./gradlew --stop
     ```
   
   ---
   
   ## Final Notes
   
   This is a foundation-laying change. By merging now, we reduce friction for 
subsequent modernization (Java 17 adoption, Jakarta alignment, build caching 
improvements) without forcing immediate code-level migrations.
   
   Thanks for reviewing—feedback on any ancillary warnings you observe during 
local builds is very welcome. Let’s merge early to surface any edge-case plugin 
interactions sooner.
   
   <!-- 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:
   - [x] 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 d...@geode.apache.org.
   -->
   


-- 
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: notifications-unsubscr...@geode.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to