Fix JAXB compilation warnings in geode-wan distributedTest

[JinwooHwang]

Overview

This PR resolves JAXB-related compilation warnings in the geode-wan module's distributed test compilation by adding the missing javax.xml.bind:jaxb-api dependency.

Problem

When compiling the geode-wan:compileDistributedTestJava task, the following warnings were generated:

warning: unknown enum constant XmlAccessType.FIELD
  reason: class file for jakarta.xml.bind.annotation.XmlAccessType not found
warning: unknown enum constant XmlAccessType.FIELD
warning: unknown enum constant XmlAccessType.FIELD
  reason: class file for jakarta.xml.bind.annotation.XmlAccessType not found
warning: unknown enum constant XmlAccessType.FIELD
warning: unknown enum constant XmlAccessType.FIELD
  reason: class file for jakarta.xml.bind.annotation.XmlAccessType not found
warning: unknown enum constant XmlAccessType.FIELD
warning: unknown enum constant XmlAccessType.FIELD

Root Cause

The distributed test code in geode-wan references JAXB annotations (such as @XmlAccessorType) through transitive dependencies from geode-core and other modules. However, the JAXB API was not explicitly declared as a compile-time dependency for the distributedTest source set.

This caused the Java annotation processor to be unable to resolve the XmlAccessType enum during compilation, resulting in the warnings above.

Solution

Added javax.xml.bind:jaxb-api to the distributedTestCompileOnly configuration in geode-wan/build.gradle:

distributedTestCompileOnly('javax.xml.bind:jaxb-api')

Why compileOnly scope?

The compileOnly scope is appropriate here because:

• ✅ JAXB API is only needed at compile time for annotation processing
• ✅ Runtime implementation is provided by other modules' dependencies
• ✅ Keeps the test classpath minimal and avoids duplicate dependencies
• ✅ Consistent with Java 17+ JAXB dependency patterns

Changes

Modified Files

• geode-wan/build.gradle - Added JAXB API dependency to distributedTest compile classpath

Diff Summary

  distributedTestImplementation(project(':geode-gfsh'))
  distributedTestImplementation(project(':geode-dunit'))
  distributedTestImplementation(project(':geode-junit'))

+ distributedTestCompileOnly('javax.xml.bind:jaxb-api')
  distributedTestImplementation('mx4j:mx4j')
  distributedTestImplementation('org.awaitility:awaitility')

Testing

Verification Steps

1. Clean build environment
2. Run compilation: ./gradlew :geode-wan:compileDistributedTestJava
3. Verify no JAXB warnings appear
4. Build completes successfully

Test Results

> Task :geode-wan:compileDistributedTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

BUILD SUCCESSFUL in 4m 35s
51 actionable tasks: 2 executed, 15 from cache, 34 up-to-date

✅ No JAXB warnings
✅ Build successful
✅ All tasks completed without errors

Related Modules

Other Geode modules follow a similar pattern for JAXB dependencies:

Module	JAXB Dependency Scope
geode-core	implementation
geode-gfsh	implementation
geode-connectors	implementation
geode-web-api	implementation
geode-lucene	implementation
geode-assembly	distributedTestImplementation

This change brings geode-wan in line with the established pattern for handling JAXB dependencies across the project.

Impact

Build Impact

• ✅ Eliminates compilation warnings
• ✅ No runtime behavior changes
• ✅ No test failures introduced
• ✅ Minimal dependency footprint

Compatibility

• ✅ Compatible with Java 17+
• ✅ No breaking changes
• ✅ Backward compatible

Checklist

• Code builds successfully
• No new compilation warnings
• Changes are minimal and focused
• Follows existing project patterns
• Commit message is comprehensive
• No runtime behavior changes

Additional Context

This fix is part of ensuring clean compilation across all Geode modules and maintaining consistency in dependency management, particularly for Java 17+ where JAXB was removed from the JDK and must be explicitly included as a dependency.

For all changes, please confirm:

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

[JinwooHwang]

Hi @raboof , all checks have passed. Thank you.

[JinwooHwang]

Thank you so much for your support @raboof