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

Show file tree
Hide file tree
Changes from all commits
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
10 changes: 10 additions & 0 deletions .github/dependabot.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
version: 2

@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: Dependabot Configuration

This Dependabot setup is well-configured for automated dependency updates. A few notes:

  • Weekly Maven updates: Will check for plugin and dependency updates
  • Weekly GitHub Actions updates: Will keep your CI/CD workflows current

Optional enhancement: Consider setting open-pull-requests-limit if you want to limit concurrent PRs:

updates:
  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

Also consider adding labels or assignees to make PRs easier to manage:

labels: ["dependencies"]
reviewers: ["bernardladenthin"]

These are optional but helpful for managing many dependency updates.

updates:
- package-ecosystem: "maven"
directory: "/"
schedule:

@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! Weekly dependency updates for Maven dependencies and GitHub Actions.

Note: This PR's pom.xml changes require careful testing in CI. The workflow (.github/workflows/release.yaml) was not updated to match the new Central Publishing Maven Plugin configuration - there's a critical mismatch between the pom.xml and workflow that will cause release builds to fail. Be sure to coordinate the workflow updates before merging this PR or releasing.

interval: "weekly"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
69 changes: 32 additions & 37 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 All @@ -62,13 +50,13 @@
<dependency>
<groupId>org.jetbrains</groupId>
<artifactId>annotations</artifactId>
<version>24.1.0</version>
<version>26.1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.21.2</version>
<version>2.21.3</version>
</dependency>
</dependencies>

Expand All @@ -77,7 +65,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
<version>3.15.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
Expand All @@ -104,7 +92,7 @@
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.1</version>
<version>3.5.0</version>
<executions>
<!-- Copy custom cuda libs to the output directory -->
<execution>
Expand Down Expand Up @@ -132,7 +120,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.3.0</version>
<version>3.4.0</version>
<executions>
<execution>
<id>attach-sources</id>
Expand All @@ -145,7 +133,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.5.0</version>
<version>3.12.0</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 bump from 3.5.0 → 3.12.0 is a significant jump. This plugin was previously at 3.5.0, now 3.12.0.

Good news: This update is a stable release, not a beta. However, with such a version jump (3.5 → 3.12), ensure:

  1. Javadoc generation still works as expected on Java 1.8 source
  2. Test that mvn package -P release successfully attaches javadoc JARs
  3. Run a full test cycle before releasing

The corresponding update in the main build section is the same version, so at least they're consistent now.

<configuration>
<source>1.8</source>
</configuration>
Expand All @@ -166,35 +154,42 @@
<id>release</id>
<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>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>3.1.0</version>
<version>3.2.8</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.10.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>
<version>3.4.2</version>
<version>3.5.0</version>
<executions>
<!-- Pick class files AND libs from custom output
directory -->
Expand Down
Loading