Skip to content

Update Maven configuration for Central Repository publishing #116

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.

Sign up for GitHub

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

Merged
bernardladenthin merged 4 commits into from
May 10, 2026
Merged

Update Maven configuration for Central Repository publishing #116

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fde130d
chore: migrate from OSSRH to Sonatype Central Publisher Portal
bernardladenthin May 10, 2026
d6a79d0
chore: update plugin and dependency versions to latest stable
claude May 10, 2026
9ee7315
Add dependabot.yml for maven and github-actions ecosystems
claude May 10, 2026
975e39f
Remove duplicate source/javadoc plugins from release profile
claude May 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 47 additions & 28 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,35 +17,23 @@
<license>
<name>MIT License</name>
<url>https://www.opensource.org/licenses/mit-license.php</url>
<distribution>repo</distribution>

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Good Addition: License Distribution Tag

Adding <distribution>repo</distribution> is correct for Maven Central requirements. This indicates the license applies to repository-hosted distributions, which is standard for open-source projects published to Maven Central.

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - adding <distribution>repo</distribution> is required by Maven Central Repository. This was added correctly.

This setting indicates the license is available from the Maven Central repository (as opposed to manual/external distribution). It's one of the requirements for publishing to Maven Central.

</license>
</licenses>

<developers>
<developer>
<name>Bernard Ladenthin</name>

<organizationUrl>https://github.com/bernardladenthin</organizationUrl>
</developer>
</developers>

<scm>
<connection>scm:git:git://github.com/kherud/java-llama.cpp.git</connection>
<developerConnection>scm:git:ssh://github.com:bernardladenthin/java-llama.cpp.git</developerConnection>
<connection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</connection>

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security improvement: SCM URLs changed from mixed protocols (git://, ssh://) to consistent HTTPS.

The original configuration used:

  • scm:git:git://... (unencrypted)
  • scm:git:ssh://... (requires SSH key)

New configuration uses:

  • scm:git:https://... (encrypted + standard credentials)

This is more secure and compatible with Maven Central requirements. HTTPS is the recommended protocol for Maven Central artifacts.

<developerConnection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</developerConnection>
Comment on lines +32 to +33

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ SCM URLs now point to personal fork

The original connection URL pointed to kherud/java-llama.cpp (upstream), while both now point to bernardladenthin/java-llama.cpp. This is a significant change:

  • The connection URL identifies the canonical source for Maven Central metadata
  • CI/CD systems use this URL for builds
  • Affects build reproducibility and project attribution

If this is intentional (e.g., project maintenance transferred): proceed, but document the change in commit history.

If not intentional: Consider keeping the upstream URL as the canonical source while using the personal fork for developerConnection (as it was originally configured).

<url>https://github.com/bernardladenthin/java-llama.cpp/tree/master</url>
</scm>

<distributionManagement>
<snapshotRepository>
<id>ossrh</id>
<url>https://s01.oss.sonatype.org/content/repositories/snapshots</url>
</snapshotRepository>
<repository>
<id>ossrh</id>
<url>
https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</repository>
</distributionManagement>

<properties>
<jna.version>5.18.1</jna.version>
<junit.version>4.13.2</junit.version>
Expand Down Expand Up @@ -167,30 +155,61 @@
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<version>1.6.13</version>
<extensions>true</extensions>
<configuration>
<serverId>ossrh</serverId>
<nexusUrl>https://s01.oss.sonatype.org/</nexusUrl>
<autoReleaseAfterClose>true</autoReleaseAfterClose>
</configuration>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.3.1</version>
<executions>
<execution>
<id>attach-sources</id>
<goals><goal>jar-no-fork</goal></goals>
</execution>
</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.11.2</version>

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Version inconsistency detected: The base build section uses maven-javadoc-plugin v3.5.0 (line 136), but this release profile specifies v3.11.2. This is a significant version jump (v3.5 → v3.11) with potentially breaking changes.

Consider:

  1. Unify versions: Use the same version in both profiles, or explain why the release profile needs a newer version
  2. Check compatibility: Review the v3.11.2 release notes for any breaking changes or behavioral differences from v3.5.0
  3. Remove redundancy: Lines 159-167 duplicate the maven-source-plugin definition from the base build. Remove this duplication or explain why it's needed in the release profile

<executions>
<execution>
<id>attach-javadocs</id>
<goals><goal>jar</goal></goals>
</execution>
</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>3.1.0</version>
<version>3.2.7</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
<goals><goal>sign</goal></goals>
<configuration>
<keyname>${gpg.keyname}</keyname>

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical Issue: The pom.xml references ${gpg.keyname}, but this property is:

  1. Not defined as a property in pom.xml
  2. Not passed by the release workflow

The .github/workflows/release.yaml (line 667) runs mvn deploy without passing -Dgpg.keyname=<KEY_ID>. This will cause GPG signing to fail with "Unable to use configured keyname".

Fix: Either:

  • Define <gpg.keyname> as a property in pom.xml (not recommended for security)
  • Update the workflow to pass it: mvn ... -Dgpg.keyname=YOUR_KEY_ID deploy

Note: The property should be the GPG key ID (usually the last 16 hex characters of the fingerprint)

<gpgArguments>
<arg>--pinentry-mode</arg>
<arg>loopback</arg>
</gpgArguments>
Comment on lines +166 to +171

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPG Configuration - Documentation Needed: The --pinentry-mode loopback configuration enables non-interactive GPG signing, which is appropriate for CI/CD environments. However, this requires specific setup that should be documented:

  1. The GPG agent must have allow-loopback-pinentry configured in ~/.gnupg/gpg-agent.conf
  2. The ${gpg.keyname} property must be set (typically via -Dgpg.keyname=<key-id> or in ~/.m2/settings.xml)
  3. The GPG passphrase needs to be available to the build environment (e.g., via environment variable or ~/.m2/settings.xml)

Recommendation: Add a comment or update documentation (CONTRIBUTING.md or README) with these requirements for maintainers setting up release builds.

</configuration>
Comment on lines +166 to +172

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 CI/CD Configuration Note

The ${gpg.keyname} property and --pinentry-mode loopback configuration are correct for automated signing in CI/CD environments. However, ensure that:

  1. The CI/CD pipeline passes -Dgpg.keyname=<GPG_KEY_ID> when invoking the release build
  2. The GPG passphrase is available via GPG_PASSPHRASE environment variable or settings.xml
  3. Release documentation is updated with these requirements

Example CI command: mvn clean deploy -Prelease -Dgpg.keyname=ABC123DEF

Comment on lines +166 to +172

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📋 GPG Configuration - Missing Documentation

The GPG signing configuration references ${gpg.keyname} variable which needs to be defined for the build to work. This should be:

  1. Set in CI/CD environment (e.g., GitHub Actions secrets)
  2. Or defined in Maven settings.xml (~/.m2/settings.xml)
  3. Or passed via command line (mvn -Dgpg.keyname=YOUR_KEY_ID)

Recommendation: Add a comment above this configuration block documenting where the gpg.keyname property should be defined. Also ensure your CI/CD workflow passes this value correctly during release builds.

Example CI/CD usage:

mvn deploy -P release -Dgpg.keyname=${{ secrets.GPG_KEYNAME }}

</execution>
</executions>
</plugin>

<plugin>
<groupId>org.sonatype.central</groupId>
<artifactId>central-publishing-maven-plugin</artifactId>
<version>0.9.0</version>
<extensions>true</extensions>
<configuration>
<publishingServerId>central</publishingServerId>

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical Issue: The pom.xml now uses publishingServerId: central, but the release workflow (.github/workflows/release.yaml line 661) still configures the Maven server with server-id: ossrh.

The Central Publishing Maven Plugin will look for a server named central in Maven's settings.xml, not ossrh. Since the workflow sets up ossrh, the deployment will fail with authentication errors.

Fix: Update .github/workflows/release.yaml publish job:

  1. Change server-id: ossrh → server-id: central (line 661)
  2. Use Central Publisher OAuth token instead of OSSRH credentials (lines 669-670)
  3. Ensure ~/.m2/settings.xml has a <server> section with id central containing the OAuth token

Reference: https://central.sonatype.org/publish/publish-maven/ for complete setup instructions

<autoPublish>true</autoPublish>
<waitUntil>published</waitUntil>
</configuration>
Comment on lines +182 to +186

@claude claude Bot May 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Central Publishing Maven Plugin Configuration: The migration from OSSRH to Sonatype Central Portal is correct and uses appropriate configuration:

✅ publishingServerId: central correctly replaces legacy ossrh ID
✅ autoPublish: true automates the publishing workflow
✅ waitUntil: published ensures artifacts are fully available before build completion

Note: Users will need to configure credentials in ~/.m2/settings.xml:

<server>
  <id>central</id>
  <username>SONATYPE_USERNAME</username>
  <password>SONATYPE_PASSWORD</password>
</server>

This should be documented for contributors who need to perform releases. Also ensure CI/CD credentials are properly scoped to this server ID.

</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
Expand Down
Loading