Backport to branch(3) : Add release flows for HashStore and TableStore

[feeblefakie]

This is an automated backport of the following:

• Original PR: Add release flows for HashStore and TableStore #268
• Backported commit: 20cc6b5

Please merge this PR after all checks have passed.

[gemini-code-assist]

Summary of Changes

Hello @feeblefakie, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This backport introduces comprehensive release flows for the ScalarDL HashStore and TableStore Java client SDKs. It establishes Maven publishing configurations, standardizes naming conventions across various build and command-line components, and refines the TableStore client API by removing an unused method. These changes are crucial for streamlining the release process and improving the consistency and maintainability of the client SDKs.

Highlights

• Maven Publishing Configuration: New archive.gradle files have been added for both HashStore and TableStore. These files define the Maven publishing configurations for their respective Java client SDKs, including POM details, artifact types (JAR, Javadoc, sources, distZip, distTar), and developer information, enabling streamlined release processes.
• Standardized Naming Conventions: The application names and command names for both HashStore and TableStore command-line tools have been standardized. The naming convention has been updated from scalardl-hash-store to scalardl-hashstore and scalardl-table-store to scalardl-tablestore across build.gradle files, command-line tool definitions, and their corresponding test files for consistency.
• Javadoc and Distribution Packaging: Javadoc generation and distribution ZIP packaging configurations have been added to the build.gradle files for both HashStore and TableStore. This ensures that proper documentation is generated and that the client SDKs are packaged correctly for distribution.
• TableStore Client API Refinement: The listContracts method, its related import, and its corresponding test case have been removed from TableStoreClientService.java and TableStoreClientServiceTest.java. This indicates a cleanup or refactoring of the TableStore client API, removing an apparently unused or deprecated functionality.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request backports changes to add release flows for HashStore and TableStore. The changes include adding Maven publishing configurations, updating Javadoc generation, and standardizing application names. The changes are mostly correct, but I've found a potential issue in the Gradle build scripts where the logic to apply publishing configuration is fragile and might not work as expected depending on how Gradle is invoked. I've provided suggestions to make it more robust.

[gemini-code-assist]

The condition project.gradle.startParameter.taskNames[0].endsWith(...) is fragile. It only checks the first task specified on the command line. If other tasks are run before the publish task (e.g., gradle clean publish), this condition will be false, and the publishing configuration will not be applied.

To make this more robust, you should check if any of the requested tasks is a publish task. This will correctly detect the intention to publish regardless of other tasks on the command line.

if (project.gradle.startParameter.taskNames.any { it.endsWith('publish') || it.endsWith('publishToMavenLocal') }) {
    apply from: 'archive.gradle'
}

[gemini-code-assist]

The condition project.gradle.startParameter.taskNames[0].endsWith(...) is fragile. It only checks the first task specified on the command line. If other tasks are run before the publish task (e.g., gradle clean publish), this condition will be false, and the publishing configuration will not be applied.

To make this more robust, you should check if any of the requested tasks is a publish task. This will correctly detect the intention to publish regardless of other tasks on the command line.

if (project.gradle.startParameter.taskNames.any { it.endsWith('publish') || it.endsWith('publishToMavenLocal') }) {
    apply from: 'archive.gradle'
}