internal: Migrate to Sonatype Central Portal #3960
Conversation
There was a problem hiding this comment.
Hello @xerial, I'm Gemini Code Assist1! 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!
Summary of Changes
Greetings! Gemini or gemini-code-assist here, providing a summary of this pull request. This PR focuses on migrating the project's publishing setup from the older Sonatype OSSRH system to the new Sonatype Central Portal. This involves removing the explicit sbt-sonatype plugin and updating the build configuration to use the new publishing endpoints and potentially relying on built-in sbt or other plugin capabilities for Central Portal integration.
Highlights
- Sonatype Migration: The primary goal is to update the build process to publish artifacts to the new Sonatype Central Portal.
- Plugin Removal: The
sbt-sonatypeplugin, previously used for Sonatype integration, has been removed. - Publishing Configuration Update: The
publishTosetting inbuild.sbthas been updated to conditionally point to the Sonatype Central Portal snapshot repository for snapshot builds, while using local staging for releases. - Removal of Old Settings: Several Sonatype-specific settings (
sonatypeProfileName,sonatypeSessionName) and related lint exclusions have been removed from the build configuration.
Changelog
- build.sbt
- Updated the
ThisBuild / publishTosetting (lines 157-160) to use the Sonatype Central Portal snapshot URL for snapshot builds and local staging for releases. - Removed
Global / excludeLintKeysfor Sonatype settings (line 194). - Removed the block defining
sonatypeProfileNameandsonatypeSessionNamefrom the root project settings (lines 202-214). - Minor indentation adjustment for a dependency exclusion (line 966).
- Updated the
- project/plugin.sbt
- Removed the
sbt-sonatypeplugin dependency (line 5). - Minor formatting adjustment for the
SCALAJS_VERSIONdefinition (line 22).
- Removed the
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
-
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. ↩
There was a problem hiding this comment.
Code Review
This PR begins the important work of migrating to the new Sonatype Central Portal. The changes in the root build.sbt and project/plugin.sbt correctly remove the old sbt-sonatype plugin and update the snapshot publishing URL.
However, there are a couple of critical concerns that need to be addressed for a successful and complete migration:
-
Incomplete Migration for Sub-Projects: The migration efforts seem to be confined to the root project. Essential sub-projects like
sbt-airframeandairspec(and their respectivebuild.sbtandproject/plugin.sbtfiles) still appear to rely on the oldsbt-sonatypeplugin and its settings (e.g.,sonatypePublishToBundle.value,sonatypeProfileName). This inconsistency will likely lead to publishing failures or the use of deprecated infrastructure for these modules. The migration strategy needs to be applied uniformly across all publishing sub-projects.- Relevant files not updated in this PR include:
sbt-airframe/build.sbt(e.g., lines 28, 31)sbt-airframe/project/plugin.sbt(e.g., line 3, still addssbt-sonatype)airspec/build.sbt(e.g., lines 39-41)- The
project/plugin.sbtforairspecwould also need similar updates.
- Relevant files not updated in this PR include:
-
Release Publishing Configuration (
localStaging.value): There's a critical question regarding how releases will be published to the new Sonatype Central Portal vialocalStaging.valuein the rootbuild.sbt. This needs clarification to ensure releases are correctly routed to the new staging mechanism. A specific comment has been added tobuild.sbton this point.
Due to these concerns, I recommend addressing these points before merging.
Summary of Findings
- Incomplete Migration for Sub-Projects: The migration to Sonatype Central Portal is not applied to sub-projects like
sbt-airframeandairspec, which still use the oldsbt-sonatypeplugin and settings. This is a critical issue that will lead to inconsistent or failed publishing. - Release Publishing Configuration with
localStaging.value: The use oflocalStaging.valuefor release publishing inbuild.sbtis unclear and potentially problematic after removingsbt-sonatype. If not correctly configured for the new Sonatype Central Portal's staging repository, releases will fail. This is a critical issue. - Stylistic Improvement: Indentation: In
build.sbt(fluentd dependencies), the indentation ofexclude ("junit", "junit")was adjusted for consistency. This is a minor stylistic improvement. (Not commented directly due to review severity settings). - Stylistic Improvement: Alignment: In
project/plugin.sbt, whitespace was added to align theval SCALAJS_VERSIONdeclaration. This is a minor stylistic improvement. (Not commented directly due to review severity settings).
Merge Readiness
This pull request is a good start towards migrating to the Sonatype Central Portal. However, due to the critical issues identified—namely the incomplete migration across sub-projects and the uncertainty around the localStaging.value configuration for release publishing—I recommend that these changes not be merged in their current state.
Addressing these critical points is essential to ensure that all modules can be published correctly and consistently to the new Sonatype Central Portal. Once these issues are resolved, the PR will be in a much better position for merging. As a reviewer, I am not authorized to approve pull requests; please ensure further review and approval from authorized maintainers after the requested changes are made.
| if (isSnapshot.value) Some("central-snapshots" at centralSnapshots) | ||
| else localStaging.value |
There was a problem hiding this comment.
The publishTo setting for releases now points to localStaging.value. This is a critical part of the migration, and its configuration needs to be clear.
Could you clarify what localStaging.value resolves to in the context of the new Sonatype Central Portal?
The sbt-sonatype plugin (which provided sonatypePublishToBundle.value and potentially other staging mechanisms like sonatypeStage) is being removed by this PR. For the new Sonatype Central Portal, releases typically need to be published to a specific staging repository URL (e.g., https://central.sonatype.com/service/local/staging/deploy/maven2/).
- How is
localStaging.valuedefined or where does it come from aftersbt-sonatypeis removed? - Does it correctly point to the new Sonatype Central Portal's staging repository for releases?
If localStaging.value is not configured for the new portal's requirements, or if it relied on functionality from the now-removed sbt-sonatype plugin, release publishing will likely be broken.
A common setup for publishing releases to the new Sonatype Central Portal might look like this:
ThisBuild / publishTo := {
val centralSnapshots = "https://central.sonatype.com/repository/maven-snapshots/"
val centralReleasesStaging = "https://central.sonatype.com/service/local/staging/deploy/maven2/"
if (isSnapshot.value) Some("central-snapshots" at centralSnapshots)
else Some("central-releases-staging" at centralReleasesStaging)
}Ensuring this is correctly configured is crucial for the migration.
Description
Related Issue/Task
Checklist