-
Notifications
You must be signed in to change notification settings - Fork 100
Replace publishing system #285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughUpdates documentation and Gradle configuration: README reflects new build outputs and deployment steps; core/build.gradle migrates to plugins DSL, introduces JReleaser-based publishing with local staging, and updates jar task classifiers; Gradle wrapper upgraded to 8.7. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as Developer
participant Gradle as Gradle Build
participant JR as JReleaser
participant Sonatype as Sonatype (Maven Central)
participant Nexus2 as Nexus2 (Snapshots)
Dev->>Gradle: ./gradlew clean publish
Gradle->>Gradle: Build artifacts (jar, sources, javadoc)
Gradle->>Gradle: Stage to $buildDir/staging-deploy
Dev->>Gradle: ./gradlew jreleaserDeploy
Gradle->>JR: Invoke deploy pipeline
JR->>JR: Sign artifacts (armored, ALWAYS)
alt Release version
JR->>Sonatype: Upload & close/release via staging repo
else Snapshot version
JR->>Nexus2: Upload to snapshot repository
end
JR-->>Dev: Deployment report
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
core/build.gradle (1)
206-211: Update Jacoco report DSL for Gradle 8 compatibilityThe
xml.enabledandxml.destinationproperties were removed in Gradle 8’s JaCoCo plugin. Update thejacocoTestReportblock incore/build.gradle(Lines 206–211) as follows:
- File:
core/build.gradle
Lines: 206–211
Replace the old Groovy-style DSL with the new Provider/Property-based API.jacocoTestReport { dependsOn test // tests are required to run before generating the report reports { - xml.enabled true - xml.destination file("${project.projectDir}/build/reports/jacoco/jacoco.xml") + xml.required.set(true) + xml.outputLocation.set(layout.buildDirectory.file("reports/jacoco/jacoco.xml")) } }Next steps:
- Apply this change.
- Rerun the CI workflow to verify that the Gradle 8–related CodeQL failure is resolved.
🧹 Nitpick comments (5)
core/build.gradle (5)
82-90: Replace custom sources/javadoc Jar tasks with the Java DSL to avoid deprecations.This avoids direct references to javadoc.destinationDir and keeps things Gradle‑8‑friendly.
-task javadocJar(type: Jar, dependsOn: javadoc) { - archiveClassifier.set("javadoc") - from javadoc.destinationDir -} - -task sourcesJar(type: Jar, dependsOn: classes) { - archiveClassifier.set("sources") - from sourceSets.main.allSource -}No further changes needed if you adopt
java { withSourcesJar(); withJavadocJar(); }and update publishing to usecomponents.java(already in place).
92-95: Drop manual artifacts block once using withSourcesJar/withJavadocJar.Gradle will attach them automatically to the Java component/publication.
-artifacts { - archives sourcesJar - archives javadocJar -}
131-136: Use uri(...) for the local staging Maven repo to avoid type coercion pitfalls.
layout.buildDirectory.dir(...)returns a Provider. Being explicit helps.repositories { maven { - url = layout.buildDirectory.dir('staging-deploy') + url = uri(layout.buildDirectory.dir('staging-deploy')) } }
138-152: JReleaser signing is enabled “ALWAYS”; ensure keys are wired, and avoid double signing with Gradle.
- Confirm JReleaser can read GPG key, passphrase, and user id from env/props.
- Consider disabling Gradle signing for the JReleaser path to prevent duplicated signatures, leaving it for local publishing only.
If you keep Gradle signing, gate it so it doesn’t run when deploying via JReleaser:
signing { - required { gradle.taskGraph.hasTask("publish") } + required { gradle.taskGraph.hasTask("publish") && !gradle.taskGraph.hasTask("jreleaserDeploy") } sign publishing.publications.mavenJava }
168-174: Ensure Sonatype Central credentials are configured for releases.The
mavenCentral.sonatypeblock lacks explicit credentials (often supplied via env/props). Without them,jreleaserDeploywill fail in CI.Add a short note in README and confirm CI secrets are set. If you prefer explicit Gradle properties:
mavenCentral { sonatype { active = 'ALWAYS' url = 'https://central.sonatype.com/api/v1/publisher' stagingRepository("$buildDir/staging-deploy") + // optionally read from gradle.properties + // username = findProperty('ossrhUsername') ?: System.getenv('OSSRH_USERNAME') + // password = findProperty('ossrhPassword') ?: System.getenv('OSSRH_PASSWORD') } }I can raise a follow‑up PR to add minimal docs and CI secret checks.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
README.md(1 hunks)core/build.gradle(3 hunks)gradle/wrapper/gradle-wrapper.properties(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: CodeQL
core/build.gradle
[error] 208-208: Could not find method enabled() for arguments [true] on Report xml of type org.gradle.api.reporting.internal.TaskGeneratedSingleFileReport. This likely uses an invalid Gradle DSL; replace 'xml.enabled(true)' with 'xml.enabled = true' (core/build.gradle:208).
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: JAVA 11 OS macOS-latest Gradle
🔇 Additional comments (5)
gradle/wrapper/gradle-wrapper.properties (1)
1-1: Correct Java Compatibility for Gradle Wrapper UpgradeGradle 8.7 itself still supports running on any JVM between Java 8 and Java 24 (minimum Java 8 remains supported) rather than requiring Java 17+. The stricter Java 17 + minimum only takes effect in Gradle 9.0(docs.gradle.org, gradle.org).
• Action 1: If you want to enforce Java 17 + (or another higher minimum) across your builds, update your CI matrices and the “Getting Started” section of your README to specify that requirement. Otherwise, no change is needed—users can run Gradle 8.7 with Java 8+.
• Action 2 (optional but recommended): Harden your wrapper by adding the SHA-256 checksum and switch to the smaller “–bin.zip” distribution.Suggested edits to gradle/wrapper/gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-all.zip +distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip +distributionSha256Sum=<paste_gradle_8.7_sha256_here>Improved verification script:
#!/usr/bin/env bash # 1. Check CI for enforced JDK version (drop restrictive -g filter and include .yaml) rg -n -C2 'setup-java|java-version' .github/workflows --glob '*.yml' --glob '*.yaml' # 2. Fetch Gradle 8.7 SHA-256 for wrapper hardening checksum_url=$(curl -s https://services.gradle.org/versions/all \ | jq -r '.[] | select(.version=="8.7") | .checksumUrl') curl -s "$checksum_url" | sed -n 's/^sha256:\s*//p'Likely an incorrect or invalid review comment.
README.md (3)
84-84: Grammar fix LGTM.
70-70: Documentation Update ConfirmedThe README.md has been inspected and contains no lingering references to “target/”.
Documentation changes look solid.
76-79: Clarify JReleaser deploy credentials and signing requirementsAdd the following under “Deployment”:
To deploy to the maven repository: ```bash ./gradlew clean ./gradlew publish ./gradlew jreleaserDeploy+Requirements:
+- Sonatype Central credentials:
- Environment variables: JRELEASER_MAVENCENTRAL_USERNAME, JRELEASER_MAVENCENTRAL_PASSWORD (or JRELEASER_MAVENCENTRAL_TOKEN)
- or Gradle properties: jreleaser.mavencentral.username, jreleaser.mavencentral.password (or jreleaser.mavencentral.token). (jreleaser.org)
+- GPG signing keys and passphrase:
- Environment variables: JRELEASER_GPG_PUBLIC_KEY, JRELEASER_GPG_SECRET_KEY, JRELEASER_GPG_PASSPHRASE
- or Gradle properties: jreleaser.gpg.public.key, jreleaser.gpg.secret.key, jreleaser.gpg.passphrase. (jreleaser.org)
+- Release vs SNAPSHOT flows:
- Releases: artifacts are staged under
build/staging-deploythen published to Sonatype Central.
- SNAPSHOTs: artifacts are deployed to the Sonatype snapshots repository.
</blockquote></details> <details> <summary>core/build.gradle (1)</summary><blockquote> `166-186`: **Ignore outdated snapshot endpoint recommendation** The Sonatype Central Publishing portal hosts its Maven snapshots at `https://central.sonatype.com/repository/maven-snapshots/`, so the existing `url`/`snapshotUrl` in the `nexus2 { … }` block is already correct. The suggestion to revert back to `oss.sonatype.org` or `s01.oss.sonatype.org` applies only to the legacy OSSRH UI, not the new Central Publishing system you’re using ([central.sonatype.com](https://central.sonatype.com/repository/maven-snapshots/?utm_source=chatgpt.com)). No changes are needed to your snapshot URL configuration. > Likely an incorrect or invalid review comment. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| plugins { | ||
| id 'java' | ||
| id 'maven-publish' | ||
| id 'signing' | ||
| id 'org.jreleaser' version '1.17.0' | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
With Gradle 8.7, add a Java toolchain to ensure 1.8 bytecode and enable built‑in source/javadoc jars.
- Gradle 8 runs on JDK 17+, but your library still targets Java 8. Without a toolchain, you risk producing non‑8‑compatible bytecode.
- Prefer the modern Java DSL to create sources/javadoc jars.
Apply this right after the plugins block:
plugins {
id 'java'
id 'maven-publish'
id 'signing'
id 'org.jreleaser' version '1.17.0'
}
+
+java {
+ toolchain {
+ languageVersion = JavaLanguageVersion.of(8)
+ }
+ // Replaces custom sourcesJar/javadocJar tasks
+ withSourcesJar()
+ withJavadocJar()
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| plugins { | |
| id 'java' | |
| id 'maven-publish' | |
| id 'signing' | |
| id 'org.jreleaser' version '1.17.0' | |
| } | |
| plugins { | |
| id 'java' | |
| id 'maven-publish' | |
| id 'signing' | |
| id 'org.jreleaser' version '1.17.0' | |
| } | |
| java { | |
| toolchain { | |
| languageVersion = JavaLanguageVersion.of(8) | |
| } | |
| // Replaces custom sourcesJar/javadocJar tasks | |
| withSourcesJar() | |
| withJavadocJar() | |
| } |
🤖 Prompt for AI Agents
In core/build.gradle around lines 1 to 6, the project lacks a Java toolchain and
the modern tasks to publish sources/javadoc jars; add a Java toolchain block
configured for Java 8 (targetCompatibility 1.8 / languageVersion 8) so
compilation always produces Java 8 bytecode regardless of the JDK running
Gradle, and define/use the built‑in Gradle sourcesJar and javadocJar tasks (via
the Java plugin components/publishing DSL) so source and javadoc artifacts are
produced and included in the maven-publish publication; ensure the
compileJava/task options set release or targetCompatibility to 8 if needed and
wire the new jars into the publication configuration.
Issue being fixed or feature implemented
Use JReleaser.
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit