Use JReleaser to release artifacts in Maven Central

[brfrn169]

Description

This PR configures JReleaser to release artifacts in the new Maven Central. This change is based on scalar-labs/scalardl#194.

Related issues and/or PRs

N/A

Changes made

• Introduce JReleaser

Checklist

The following is a best-effort checklist. If any items in this checklist are not applicable to this PR or are dependent on other, unmerged PRs, please still mark the checkboxes after you have read and understood each item.

• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes.
• I have considered whether similar issues could occur in other products, components, or modules if this PR is for bug fixes.
• Any remaining open issues linked to this PR are documented and up-to-date (Jira, GitHub, etc.).
• Tests (unit, integration, etc.) have been added for the changes.
• My changes generate no new warnings.
• Any dependent changes in other PRs have been merged and published.

Additional notes (optional)

N/A

Release notes

N/A

[gemini-code-assist]

Summary of Changes

Hello @brfrn169, 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 pull request significantly refactors the project's artifact release mechanism by integrating JReleaser. The change centralizes the entire publishing process to Maven Central, streamlining both release and snapshot deployments, and simplifies the build scripts of individual subprojects by removing redundant publishing and signing logic.

Highlights

• JReleaser Integration: Introduced the JReleaser Gradle plugin in the root build.gradle and configured it for releasing artifacts to Maven Central. This includes setup for both release and snapshot deployments, specifying Sonatype for releases and Nexus2 for snapshots, along with their respective staging repositories.
• Build Configuration Centralization: Centralized the definition of projectGroup and projectVersion in the root build.gradle using ext properties. These variables are now used to set the group and version for the entire project and its subprojects, promoting consistency.
• Simplified Subproject Publishing: Removed the direct Maven Central repository URLs, credentials, and explicit signing plugin configurations from individual subproject build.gradle files (core, data-loader/core, integration-test, schema-loader). Publishing is now delegated to JReleaser, which handles the final deployment from local staging directories.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 is currently in preview and 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 to provide feedback.

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. ↩

[Copilot]

Pull Request Overview

This PR configures JReleaser to release artifacts in Maven Central by removing manual signing and OSSRH publishing from Gradle modules and updating CI workflows to use JReleaser.

• Moved publishing outputs to local staging-deploy directories and removed the signing plugin and OSSRH credentials from subprojects.
• Updated GitHub Actions workflows to run ./gradlew publish and ./gradlew jreleaserDeploy, replacing legacy Maven Central upload steps.

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
schema-loader/build.gradle	Removed signing plugin and OSSRH credentials; publishing to staging directory
integration-test/build.gradle	Same removal of signing and OSSRH config; updated repo URL
data-loader/core/build.gradle	Dropped signing plugin and external repos; local staging-deploy target
core/build.gradle	Removed signing block and OSSRH repos; pointed to staging-deploy
.github/workflows/upload-artifacts.yaml	Added JReleaser publish steps; removed legacy Maven Central upload
.github/workflows/release-snapshot.yaml	Added snapshot publish and JReleaser deploy; removed legacy snapshot upload

Comments suppressed due to low confidence (3)

.github/workflows/upload-artifacts.yaml:49

• [nitpick] The step name 'Upload artifacts to Maven Central Repository' could be more specific (e.g., 'Deploy artifacts to Maven Central via JReleaser') to clearly indicate that JReleaser handles the deployment.

      - name: Upload artifacts to Maven Central Repository

.github/workflows/release-snapshot.yaml:37

• [nitpick] Consider renaming this step to 'Deploy SNAPSHOT artifacts to Maven Central via JReleaser' for consistency and clarity with the release workflow.

      - name: Upload SNAPSHOT versions of artifacts to Maven Snapshot repository

schema-loader/build.gradle:137

• The publishing repository configuration is duplicated across multiple modules. Consider extracting this into a shared Gradle script or the root project to reduce duplication and improve maintainability.

            url = layout.buildDirectory.dir('staging-deploy')

[gemini-code-assist]

Code Review

This pull request migrates the project's release process to use JReleaser for publishing artifacts to Maven Central. The changes involve adding the JReleaser plugin, centralizing version and group definitions, and updating subprojects to publish to a local staging directory for JReleaser to consume. My review focuses on improving the maintainability of the new JReleaser configuration by suggesting a dynamic way to configure staging repositories, which will make it easier to manage publishable subprojects in the future.

[Torch3333]

LGTM, thank you!

[komamitsu]

LGTM, thank you!

[feeblefakie]

LGTM! Thank you!

[komamitsu]

LGTM! 👍

[jnmt]

Almost looks good, and the dry run worked fine. I left one comment. PTAL, thank you!

[jnmt]

LGTM, thank you!