Optimize build: share OpenAPI generator JAR across client modules

[cbb330]

Summary

Share OpenAPI generator JAR across client modules to reduce build time by 10%.

Previously, each client module (hts, tableclient, jobsclient) downloaded the OpenAPI generator CLI JAR (~24MB) to its own $buildDir/bin directory. This change uses a shared location with file locking to ensure only one download occurs.

Build time improvement (./gradlew clean build -x test):

	Time
Before	311s (5m 10s)
After	280s (4m 39s)
Improvement	-31s (10% faster)

Changes

• Client-facing API Changes
• Internal API Changes
• Bug Fixes
• New Features
• Performance Improvements
• Code Style
• Refactoring
• Documentation
• Tests

Performance Improvements

• Modified client/common/codegen.build.gradle to use shared JAR location (${rootProject.buildDir}/openapi-cli)
• Updated client/common/jar_download.sh with:
  • Portable file locking using mkdir (works on Linux/macOS)
  • Download to temp file then atomic mv to final location
  • Proper error handling and lock cleanup

Before (3 separate downloads):

> Task :client:hts:setUp
Downloading openapi generator JAR in bin folder .../build/hts/bin if needed...
> Task :client:jobsclient:setUp
Downloading openapi generator JAR in bin folder .../build/jobsclient/bin if needed...
> Task :client:tableclient:setUp  
Downloading openapi generator JAR in bin folder .../build/tableclient/bin if needed...

After (1 shared download):

> Task :client:hts:setUp
Downloading openapi generator JAR in bin folder .../build/openapi-cli if needed...
Downloading openapi-generator-cli-5.3.0.jar...
> Task :client:jobsclient:setUp
openapi-generator-cli-5.3.0.jar exists.
> Task :client:tableclient:setUp
openapi-generator-cli-5.3.0.jar exists.

Testing Done

• Manually Tested on local docker setup. Please include commands ran, and their output.
• Added new tests for the changes made.
• Updated existing tests to reflect the changes made.
• No tests added or updated. Please explain why. If unsure, please feel free to ask for help.
• Some other form of testing like staging or soak time in production. Please explain.

Manual Testing

1. Verified JAR is downloaded once to shared location and reused by other client modules
2. Verified file locking works correctly with parallel builds (concurrent tasks wait for download)
3. Measured before/after build times with ./gradlew clean build -x test

No Tests Added

This is a build infrastructure change that doesn't affect runtime behavior. The optimization is validated by the build output showing "exists" messages for subsequent client modules.

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.

🤖 Generated with Claude Code

[jiang95-dev]

Thanks, the script is great and bulletproof! However, I think there's an alternative without using locks. We can make the setup() task only in :client:common (of course the folder must be shared), and then the clientCodeGen() task in each module to depend on the setup() task. Right now we are bringing the setup() task in each module so that's why it is executed multiple times. I think this will be more efficient since we don't need locks or temp files copy.