[
https://issues.apache.org/jira/browse/GEODE-10493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10493:
---------------------------------
Description:
h3. Current Problem
The japicmp API compatibility check is now failing in CI with binary
compatibility errors:
> Task :geode-server-all:japicmp FAILED
> Execution failed for task ':geode-server-all:japicmp'.
> Detected binary changes between geode-*-1.16.0-build.0.jar and
> geode-*-1.14.4.jar
> See failure report at
> build/reports/rich-report-japi-v1.14.4-1.16.0-build.0.html
This failure began appearing after build system fixes were applied during the
Gradle 7.6.6 migration (GEODE-10490).
*
h3. Investigation Findings
h4. japicmp Was Previously Broken
Analysis reveals that japicmp had been silently non-functional due to class
loading issues in composite builds:
* Original configuration used compile-time imports that failed to load custom
rules
* Task would appear to pass but wasn't actually enforcing API compatibility
* API violations accumulated undetected across multiple releases
h4. Stale Baseline Comparison
The failure compares against an outdated baseline:
* Current comparison: 1.16.0-build.0 vs 1.14.4 (missing 1.15.x series)
* Missing versions: 1.15.0, 1.15.1, 1.15.2 from
[geode-old-versions|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
directory
* Result: Excessive accumulated changes spanning multiple release cycles
h4. What the Fix in GEODE-10490 Actually Did
The Gradle migration included a fix to japicmp class loading:
// Before: Hard imports that failed in composite builds
import org.apache.geode.gradle.japicmp.GeodeApiRegressionRule
// After: Runtime loading with graceful fallback
def getJapicmpClassIfAvailable(String className) {
try {
return Class.forName(className)
} catch (ClassNotFoundException e) {
return null
}
}
This restored japicmp to working order, which then exposed years of untracked
API changes.
h3. Proposed Solution
h4. 1. Update Baseline Versions
* Add missing directories: 1.15.0/, {{{}1.15.1/{}}}, {{1.15.2/}}
* Change comparison from 1.14.4 → 1.16.0 to 1.15.2 → 1.16.0
* Focus review on recent, relevant changes only
h4. 2. Update Exception Rules
* Clean up japicmp_exceptions.json for correct 1.15.2 baseline
* Remove bulk exceptions that were masking the baseline problem
* Document legitimate API changes between 1.15.2 and 1.16.0
h4. 3. Improve CI Diagnostics
* Add japicmp report artifact upload for failed builds
* Enable developers to download and examine detailed compatibility reports
* Reduce debugging time for future API compatibility issues
h3. Expected Benefits
*Immediate:*
* Unblock CI builds by addressing accumulated technical debt
* Provide actionable reports showing specific API compatibility violations
* Restore proper API compatibility enforcement going forward
*Long-term:*
* Prevent future API compatibility violations from going undetected
* Improve developer productivity with better diagnostic information
* Establish foundation for proper API evolution governance
h3. Risk Assessment
*Low Risk:*
* Changes only affect build tooling and baseline comparison
* No impact on runtime behavior or public APIs
* Fixes restore intended functionality rather than changing behavior
*High Value:*
* Addresses significant technical debt in API compatibility checking
* Prevents future accumulation of undetected violations
* Improves development workflow and CI reliability
h3. Acceptance Criteria
* japicmp task passes with updated 1.15.2 baseline
* Exception rules properly handle legitimate API changes
* CI uploads diagnostic reports on japicmp failures
* Build process documentation updated to include baseline maintenance
was:
h3. Current Problem
The japicmp API compatibility check is now failing in CI with binary
compatibility errors:
*
*
*
*
This failure began appearing after build system fixes were applied during the
Gradle 7.6.6 migration (GEODE-10490).
h3. Investigation Findings
h4. japicmp Was Previously Broken
Analysis reveals that japicmp had been silently non-functional due to class
loading issues in composite builds:
* Original configuration used compile-time imports that failed to load custom
rules
* Task would appear to pass but wasn't actually enforcing API compatibility
* API violations accumulated undetected across multiple releases
h4. Stale Baseline Comparison
The failure compares against an outdated baseline:
* Current comparison: 1.16.0-build.0 vs 1.14.4 (missing 1.15.x series)
* Missing versions: 1.15.0, 1.15.1, 1.15.2 from
[geode-old-versions|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
directory
* Result: Excessive accumulated changes spanning multiple release cycles
h4. What the Fix in GEODE-10490 Actually Did
The Gradle migration included a fix to japicmp class loading:
*
*
*
*
This restored japicmp to working order, which then exposed years of untracked
API changes.
h3. Proposed Solution
h4. 1. Update Baseline Versions
* Add missing directories:
[1.15.0|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html],
{{{}1.15.1/{}}}, {{1.15.2/}}
* Change comparison from 1.14.4 → 1.16.0 to 1.15.2 → 1.16.0
* Focus review on recent, relevant changes only
h4. 2. Update Exception Rules
* Clean up
[japicmp_exceptions.json|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
for correct 1.15.2 baseline
* Remove bulk exceptions that were masking the baseline problem
* Document legitimate API changes between 1.15.2 and 1.16.0
h4. 3. Improve CI Diagnostics
* Add japicmp report artifact upload for failed builds
* Enable developers to download and examine detailed compatibility reports
* Reduce debugging time for future API compatibility issues
h3. Expected Benefits
*Immediate:*
* Unblock CI builds by addressing accumulated technical debt
* Provide actionable reports showing specific API compatibility violations
* Restore proper API compatibility enforcement going forward
*Long-term:*
* Prevent future API compatibility violations from going undetected
* Improve developer productivity with better diagnostic information
* Establish foundation for proper API evolution governance
h3. Risk Assessment
*Low Risk:*
* Changes only affect build tooling and baseline comparison
* No impact on runtime behavior or public APIs
* Fixes restore intended functionality rather than changing behavior
*High Value:*
* Addresses significant technical debt in API compatibility checking
* Prevents future accumulation of undetected violations
* Improves development workflow and CI reliability
h3. Acceptance Criteria
* japicmp task passes with updated 1.15.2 baseline
* Exception rules properly handle legitimate API changes
* CI uploads diagnostic reports on japicmp failures
* Build process documentation updated to include baseline maintenance
*
*
> japicmp API compatibility task failing after being restored during Gradle
> 7.6.6 migration
> -----------------------------------------------------------------------------------------
>
> Key: GEODE-10493
> URL: https://issues.apache.org/jira/browse/GEODE-10493
> Project: Geode
> Issue Type: Improvement
> Reporter: Jinwoo Hwang
> Assignee: Jinwoo Hwang
> Priority: Major
>
> h3. Current Problem
> The japicmp API compatibility check is now failing in CI with binary
> compatibility errors:
>
> > Task :geode-server-all:japicmp FAILED
> > Execution failed for task ':geode-server-all:japicmp'.
> > Detected binary changes between geode-*-1.16.0-build.0.jar and
> > geode-*-1.14.4.jar
> > See failure report at
> > build/reports/rich-report-japi-v1.14.4-1.16.0-build.0.html
>
> This failure began appearing after build system fixes were applied during
> the Gradle 7.6.6 migration (GEODE-10490).
> *
> h3. Investigation Findings
> h4. japicmp Was Previously Broken
> Analysis reveals that japicmp had been silently non-functional due to class
> loading issues in composite builds:
> * Original configuration used compile-time imports that failed to load
> custom rules
> * Task would appear to pass but wasn't actually enforcing API compatibility
> * API violations accumulated undetected across multiple releases
> h4. Stale Baseline Comparison
> The failure compares against an outdated baseline:
> * Current comparison: 1.16.0-build.0 vs 1.14.4 (missing 1.15.x series)
> * Missing versions: 1.15.0, 1.15.1, 1.15.2 from
> [geode-old-versions|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
> directory
> * Result: Excessive accumulated changes spanning multiple release cycles
> h4. What the Fix in GEODE-10490 Actually Did
> The Gradle migration included a fix to japicmp class loading:
>
>
> // Before: Hard imports that failed in composite builds
> import org.apache.geode.gradle.japicmp.GeodeApiRegressionRule
> // After: Runtime loading with graceful fallback
> def getJapicmpClassIfAvailable(String className) {
> try {
> return Class.forName(className)
> } catch (ClassNotFoundException e) {
> return null
> }
> }
>
> This restored japicmp to working order, which then exposed years of untracked
> API changes.
> h3. Proposed Solution
> h4. 1. Update Baseline Versions
> * Add missing directories: 1.15.0/, {{{}1.15.1/{}}}, {{1.15.2/}}
> * Change comparison from 1.14.4 → 1.16.0 to 1.15.2 → 1.16.0
> * Focus review on recent, relevant changes only
> h4. 2. Update Exception Rules
> * Clean up japicmp_exceptions.json for correct 1.15.2 baseline
> * Remove bulk exceptions that were masking the baseline problem
> * Document legitimate API changes between 1.15.2 and 1.16.0
> h4. 3. Improve CI Diagnostics
> * Add japicmp report artifact upload for failed builds
> * Enable developers to download and examine detailed compatibility reports
> * Reduce debugging time for future API compatibility issues
> h3. Expected Benefits
> *Immediate:*
> * Unblock CI builds by addressing accumulated technical debt
> * Provide actionable reports showing specific API compatibility violations
> * Restore proper API compatibility enforcement going forward
> *Long-term:*
> * Prevent future API compatibility violations from going undetected
> * Improve developer productivity with better diagnostic information
> * Establish foundation for proper API evolution governance
> h3. Risk Assessment
> *Low Risk:*
> * Changes only affect build tooling and baseline comparison
> * No impact on runtime behavior or public APIs
> * Fixes restore intended functionality rather than changing behavior
> *High Value:*
> * Addresses significant technical debt in API compatibility checking
> * Prevents future accumulation of undetected violations
> * Improves development workflow and CI reliability
> h3. Acceptance Criteria
> * japicmp task passes with updated 1.15.2 baseline
> * Exception rules properly handle legitimate API changes
> * CI uploads diagnostic reports on japicmp failures
> * Build process documentation updated to include baseline maintenance
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
