Fix Swagger annotation warnings in geode-dunit compilation

[JinwooHwang]

Overview

This PR resolves Swagger/OpenAPI annotation-related compilation warnings in the geode-dunit module by adding the missing io.swagger.core.v3:swagger-annotations dependency.

Problem

When compiling the geode-dunit:compileJava task, the following warnings were generated:

warning: unknown enum constant AccessMode.READ_ONLY
  reason: class file for io.swagger.v3.oas.annotations.media.Schema$AccessMode not found
warning: unknown enum constant AccessMode.READ_ONLY
warning: unknown enum constant AccessMode.READ_ONLY
  reason: class file for io.swagger.v3.oas.annotations.media.Schema$AccessMode not found
warning: unknown enum constant AccessMode.READ_ONLY
warning: unknown enum constant AccessMode.READ_ONLY
  reason: class file for io.swagger.v3.oas.annotations.media.Schema$AccessMode not found
warning: unknown enum constant AccessMode.READ_ONLY

Root Cause

The geode-dunit module references Swagger/OpenAPI annotations (such as @Schema with AccessMode) through transitive dependencies from geode-core and geode-gfsh, both of which have swagger-annotations as implementation dependencies.

However, the Swagger annotations API was not explicitly declared as a compile-time dependency for geode-dunit. This caused the Java annotation processor to be unable to resolve the AccessMode enum during compilation, resulting in the warnings above.

Dependency Chain

• geode-dunit → geode-core → swagger-annotations (implementation)
• geode-dunit → geode-gfsh → swagger-annotations (implementation)

The transitive nature of these dependencies meant that while the annotations were available at runtime, they weren't available to the annotation processor at compile time.

Solution

Added io.swagger.core.v3:swagger-annotations to the compileOnly configuration in geode-dunit/build.gradle:

compileOnly('io.swagger.core.v3:swagger-annotations')

Why compileOnly scope?

The compileOnly scope is the appropriate choice here because:

• ✅ Swagger annotations API is only needed at compile time for annotation processing
• ✅ Runtime implementation is provided by transitive dependencies from geode-core and geode-gfsh
• ✅ Keeps the classpath minimal and avoids duplicate dependencies
• ✅ Prevents dependency version conflicts
• ✅ Consistent with established patterns in other Geode modules

Changes

Modified Files

• geode-dunit/build.gradle - Added Swagger annotations API dependency to compile classpath

Diff Summary

 dependencies {
   api(platform(project(':boms:geode-all-bom')))
+  compileOnly('io.swagger.core.v3:swagger-annotations')
   implementation(project(':geode-logging'))
   implementation(project(':geode-serialization'))
   implementation(project(':geode-membership'))

Testing

Verification Steps

1. Clean build environment
2. Run compilation: ./gradlew :geode-dunit:compileJava
3. Verify no Swagger annotation warnings appear
4. Build completes successfully

Test Results

> Task :geode-dunit:compileJava
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 14s
48 actionable tasks: 1 executed, 47 up-to-date

✅ No Swagger/OpenAPI annotation warnings
✅ Build successful
✅ All tasks completed without errors
✅ No runtime behavior changes

Related Modules

Other Geode modules follow similar patterns for Swagger annotations dependencies:

Module	Swagger Dependency Scope	Use Case
geode-core	implementation	Core REST API models
geode-gfsh	implementation	Management API integration
geode-management	testCompileOnly	Test compilation only
geode-deployment-legacy	compileOnly	Compile-time annotations
geode-assembly	distributedTestCompileOnly	Distributed test compilation
geode-server-all	serverNonOptional	Server runtime

This change brings geode-dunit in line with the established pattern for handling Swagger annotations dependencies across the project, particularly matching the approach used in geode-deployment-legacy which also uses compileOnly.

Impact

Build Impact

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

Performance

• ✅ No performance impact (compile-time only)
• ✅ Slightly faster annotation processing (fewer unresolved references)

Compatibility

• ✅ Compatible with all supported Java versions
• ✅ No breaking changes
• ✅ Backward compatible
• ✅ No API changes

Benefits

1. Cleaner Build Output: Eliminates noisy warnings that can obscure real issues
2. Better Developer Experience: Developers won't see confusing annotation warnings
3. Consistent Pattern: Aligns with how other modules handle this dependency
4. Future-Proof: Ensures annotation processing works correctly for future changes
5. Documentation: Explicitly documents the compile-time dependency

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
• No test failures
• Dependency scope is appropriate

Additional Context

This fix is part of ensuring clean compilation across all Geode modules and maintaining consistency in dependency management. The Swagger annotations are used throughout the Geode codebase for REST API documentation, and this change ensures that the annotation processor has access to the necessary types during compilation.

Background on Swagger Annotations in Geode

Geode uses Swagger/OpenAPI annotations (from io.swagger.core.v3:swagger-annotations) to document its REST APIs. These annotations include:

• @Schema - Describes model schemas
• @Schema.AccessMode - Specifies access mode (READ_ONLY, WRITE_ONLY, etc.)
• Other OpenAPI metadata annotations

The annotations are processed at compile time by annotation processors, which require the annotation definitions to be available on the compile classpath, even if the code doesn't directly reference them.

Why This Wasn't Caught Earlier

The warnings only appear during compilation and don't cause build failures. They can be easily overlooked in large build outputs but should be addressed to maintain code quality and developer experience.

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 @sboorlagadda , all checks have passed. Thank you.

[JinwooHwang]

Thank you so much for your support @raboof