• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch maven

Reviewing files that changed from the base of the PR and between 2696a4d and 39cc849.

• .github/workflows/release.yml (1 hunks)
• README.md (2 hunks)
• build.gradle (2 hunks)

build.gradle (5)

3-4: Plugins added correctly.

The maven-publish and signing plugins are required for Maven Central publishing and artifact signing.

---

8-8: Version bump to 0.1.0 noted.

Version changed from 1.0.0 to 0.1.0. Confirm this is intentional and aligns with your versioning strategy—0.1.0 typically indicates early release/beta status rather than a patch release.

---

11-17: Java toolchain and packaging configuration looks good.

Explicit JDK 21 requirement and automatic sources/Javadoc JAR generation are best practices for Maven Central publishing.

---

34-79: Verify Sonatype Maven Central endpoint and license file reference.

The publishing configuration includes comprehensive POM metadata. However:

1. Sonatype endpoint URL (line 72): Verify that https://central.sonatype.com/api/v1/publisher/upload is the correct endpoint for your Maven Central account type. Sonatype has multiple publishing endpoints (e.g., s01.oss.sonatype.org for newer accounts vs. oss.sonatype.org for legacy). Confirm which one applies to your account.

2. License file path (line 48): The POM references LICENSE.md, but ensure this file exists at the repository root with the exact name and path.

---

81-89: Signing configuration: verify key handling and error behavior.

The signing block conditionally signs artifacts only if both signingKey and signingPassword are provided. This is correct, but consider:

1. Silent failure: If credentials are missing in CI/CD, the build succeeds unsigned. Add logging or make signing mandatory in production builds.

2. Key format: Ensure that GPG_PRIVATE_KEY contains the armored PGP key in the correct format (usually base64-encoded or direct ASCII-armored key). The useInMemoryPgpKeys() method expects a specific format.

3. Error propagation: Test locally that signing failures propagate correctly (e.g., corrupted key, wrong passphrase).

Would you like me to generate a verification script to check the GPG key format compatibility and signing behavior?

.github/workflows/release.yml (3)

35-41: Publish to Maven Central step: environment variables properly wired.

The publish step correctly passes Maven Central credentials and GPG signing keys via environment variables. Ensure these secrets are configured in the GitHub repository settings:

• MAVEN_CENTRAL_USERNAME
• MAVEN_CENTRAL_TOKEN
• GPG_PRIVATE_KEY
• GPG_PASSPHRASE

---

49-57: Git commit and push configuration: verify token permissions and avoid race conditions.

The README update is committed and pushed using the GITHUB_TOKEN. Key considerations:

1. Token permissions: Verify the workflow's permissions block grants contents: write access. Line 12 shows contents: write ✓

2. Race condition risk: Between publishing to Maven Central (line 35) and pushing the updated README (line 55), there is a small window where:

   • A race tag is pushed by another workflow or user
   • The README update fails partway through
   • The commit message does not match the published version

   This is typically acceptable for release workflows, but be aware.

3. Commit guard (line 54): The git diff --staged --quiet || ensures a commit only if changes exist—good practice. However, if the sed replacement fails silently (no replacements made), the step will silently skip the commit without error.

4. GitHub Actions bot account: Using github-actions[bot] is standard. Ensure this account has appropriate access.

Verify that the workflow's permissions block at line 11-12 is sufficient for the push operation. Also test locally that the sed commands produce expected changes before the commit.

---

43-47: Sed regex patterns are correct and safely capture all version occurrences in README.

Verification confirms:

• Regex safety: Patterns correctly escape \+ for sed extended regex (lines 46–47).
• Coverage: All 3 version references are matched: 2 Gradle implementations (lines 403, 411) + 1 Maven XML tag (line 421).
• False positives: No other numeric [N].[N].[N] patterns exist in README—no risk of unintended updates.

The sed commands are correct as written.

README.md (2)

7-7: Maven Central badge URL looks correct.

The badge URL format follows shields.io conventions and should render as a version badge. The coordinates com.felipestanzani/jtoon match the group and artifactId in build.gradle.

---

395-429: Installation instructions refactored correctly for Maven Central; minor consistency checks.

The new installation section appropriately prioritizes Maven Central over manual JAR downloads. The following looks good:

1. Dependency declarations: Version 0.1.0 is consistent across Gradle Groovy, Gradle Kotlin, and Maven blocks.
2. Maven coordinates: com.felipestanzani:jtoon:0.1.0 matches build.gradle configuration.
3. Documentation note: Line 425 references the Maven Central latest version page with a helpful link.
4. Fallback section: Alternative manual installation (lines 427–429) preserved for users without build tool integration.

One minor observation: ensure that once the artifact is published to Maven Central and indexed, the badge at line 7 updates automatically. Shields.io badges typically have a cache lag of a few minutes.

After the first release is published to Maven Central, verify that the badge at line 7 displays the correct version number (0.1.0) within 5–10 minutes.