chore: migrate CI to unified publish.yml with Sonatype Central Portal

[bernardladenthin]

Summary

• Delete maven.yml, snapshot.yml, maven-publish.yml — replaced by the unified pipeline
• Add publish.yml: single workflow covering build → test → publish-snapshot OR publish-release → post-publish
  • publish-snapshot: deploys to Sonatype Central Portal snapshot repo on every push to main or manual dispatch; uses environment: maven-central
  • publish-release: deploys signed release to Central Portal on v* tags; uses environment: maven-central
  • post-publish: dependency graph, Codecov, Coveralls
• Add codeql.yml: GitHub Advanced Security scanning on PRs, pushes to main, and weekly schedule
• pom.xml:
  • Replace GitHub Packages distributionManagement with Central Portal snapshotRepository
  • Replace github-java-llama GitHub Packages repository with Central Portal snapshots so the llama:5.0.0-SNAPSHOT dependency resolves correctly after java-llama.cpp publishes snapshots there
• All GitHub Actions on latest major versions (checkout@v6, setup-java@v5, upload-artifact@v7, download-artifact@v8, codecov-action@v6, maven-dependency-submission-action@v5)

Prerequisites (must be done in GitHub UI before workflows run)

1. Go to Settings → Environments → maven-central
2. Under "Deployment branches and tags", add main as an allowed branch
3. Secrets required in the maven-central environment: CENTRAL_USERNAME, CENTRAL_TOKEN, GPG_PRIVATE_KEY, GPG_PASSPHRASE
4. Repository secrets: CODECOV_TOKEN, COVERALLS_TOKEN
5. java-llama.cpp must publish its snapshot to Central Portal first (so this plugin can resolve llama:5.0.0-SNAPSHOT)

Test plan

• Push to main → build + test + publish-snapshot + post-publish
• Push v* tag → build + test + publish-release (pauses at environment approval) + post-publish
• Feature branch push / PR → build + test only; publish jobs skipped

https://claude.ai/code/session_01TPLSUAgEHPFGSoDesiPZ5N

---

Generated by Claude Code

[claude]

The project's CLAUDE.md declares Java 21 as the requirement, but this is using Java 8. To match the project specification and ensure CodeQL analyzes code as it will be compiled, this should use Java 21:

Suggested change

	with: { java-version: '8', distribution: temurin }
	with: { java-version: '21', distribution: temurin }

Also update the pom.xml compiler properties to match.

[bernardladenthin]

The project compiles Java 8 bytecode (maven.compiler.source=1.8, maven.compiler.target=1.8) and the publish.yml uses JDK 8. The CodeQL workflow uses the same version for consistency — CodeQL should analyze the code under the same JDK used to build it.

The CLAUDE.md mentions Java 21 as the runtime requirement, but the bytecode target is 1.8 and JDK 8 is the correct compiler to use here. Using Java 21 in CodeQL would also work (JDK 21 can compile 1.8 targets), but it would introduce a mismatch with the build configuration without any benefit.

---

Generated by Claude Code

[claude]

The pom.xml defines only <snapshotRepository> but should also define <releaseRepository> for release deployments to a distinct production repository URL. Add after the snapshotRepository:

<releaseRepository>
    <id>central</id>
    <url>https://central.sonatype.com/</url>
</releaseRepository>

This follows Maven best practices for multi-environment deployments.

[bernardladenthin]

This is not needed. central-publishing-maven-plugin with <extensions>true</extensions> (in the release profile) intercepts the deploy lifecycle for non-SNAPSHOT versions and uploads directly to Central Portal via its API. It does not use distributionManagement/<repository> or <releaseRepository>. Only <publishingServerId> matters for the plugin configuration.

---

Generated by Claude Code

[claude]

[claude]

Review Summary

This PR successfully consolidates the CI/CD pipeline to a unified publish.yml workflow with Sonatype Central Portal integration. Here are the key findings:

✅ Strengths

• Good consolidation: Combining 3 workflows into 1 reduces maintenance burden and complexity
• Proper secrets handling: GPG keys are configured correctly via setup-java action
• Security scanning: Addition of CodeQL provides continuous vulnerability detection
• Centralized publishing: Migration to official Maven Central Repository is industry best practice
• Conditional job logic: The publish-snapshot and publish-release jobs correctly skip on non-applicable branches

⚠️ Issues Found

1. Missing Release Repository Configuration (Important)

The pom.xml only defines snapshotRepository in distributionManagement, but the release deployment should have a corresponding repository element. While the central-publishing-maven-plugin handles the actual upload, best practice is to declare both:

<distributionManagement>
    <snapshotRepository>
        <id>central</id>
        <url>https://central.sonatype.com/repository/maven-snapshots/</url>
    </snapshotRepository>
    <repository>
        <id>central</id>
        <url>https://central.sonatype.com/repository/maven-releases/</url>
    </repository>
</distributionManagement>

2. Java Version Inconsistency (Documentation)

The CLAUDE.md specifies Java 21, but pom.xml is configured for Java 8 and the workflows use Java 8. Verify that:

• Is Java 8 intentional for this plugin?
• If Java 21 is the target, the pom.xml needs: <maven.compiler.source>21</maven.compiler.source> and <maven.compiler.target>21</maven.compiler.target>, plus workflows need java-version: '21'

3. Post-Publish Permissions Inheritance (Minor)

While not incorrect, consider explicitly setting permissions on build and test jobs for clarity:

jobs:
  build:
    permissions:
      contents: read
  test:
    permissions:
      contents: read

Test Plan Verification

Before merge, confirm:

• Feature branch push → build + test only (publish jobs skipped)
• Push to main → snapshot deploys to Central Portal successfully
• Tag v* → release deploys to Central Portal with GPG signature
• Verify environment protection rules: main branch must be added to maven-central environment in Settings
• Verify all secrets exist: CENTRAL_USERNAME, CENTRAL_TOKEN, GPG_PRIVATE_KEY, GPG_PASSPHRASE, CODECOV_TOKEN, COVERALLS_TOKEN

[claude]

Consider adding a <repository> element for releases alongside the snapshotRepository. While central-publishing-maven-plugin handles the deployment, explicitly declaring both provides clarity and follows Maven best practices:

Suggested change

	<distributionManagement>
	<repository>
	<id>github</id>
	<name>GitHub Packages</name>
	<url>https://maven.pkg.github.com/bernardladenthin/llamacpp-ai-index-maven-plugin</url>
	</repository>
	<snapshotRepository>
	<id>central</id>
	<url>https://central.sonatype.com/repository/maven-snapshots/</url>
	</snapshotRepository>
	</distributionManagement>
	<distributionManagement>
	<snapshotRepository>
	<id>central</id>
	<url>https://central.sonatype.com/repository/maven-snapshots/</url>
	</snapshotRepository>
	<repository>
	<id>central</id>
	<url>https://central.sonatype.com/repository/maven-releases/</url>
	</repository>
	</distributionManagement>

[bernardladenthin]

Not needed — see the other comment. central-publishing-maven-plugin with extensions: true replaces the standard Maven deploy plugin for release versions, so distributionManagement/<repository> is never consulted during mvn deploy -P release. Adding it would only add confusion since it would never be used.

---

Generated by Claude Code