Google Git
Sign in
apache / maven-studies / refs/heads/deploy
commit19166d123856bbb709181da2ab286678c5c1c6ae[log] [tgz]
authorHervé Boutemy <hboutemy@apache.org>Sun Oct 05 11:12:37 2025 +0200
committerHervé Boutemy <hboutemy@apache.org>Sun Oct 05 11:12:37 2025 +0200
tree63d7ae4e31051df0a88188a984b1a791cf4c2773
parent87da7d34c287bec6487bbdee4e83d8710eab1b84 [diff]
move artifacts to deploy groupId
7 files changed
tree: 63d7ae4e31051df0a88188a984b1a791cf4c2773
  1. projects/
  2. .gitignore
  3. 1.1_DISCOVERY-file.md
  4. 1.2_DISCOVERY-atEnd.md
  5. 1.3_DISCOVERY-upload-manual.md
  6. 1.4_DISCOVERY-central-publishing.md
  7. 1.5_DISCOVERY-njord.md
  8. 1.6_DISCOVERY-jreleaser.md
  9. 1.7_DISCOVERY-nxrm3-staging.md
  10. 1_DISCOVERY.md
  11. pom.xml
  12. README.md
README.md

deployment solutions study

Study to better understand maven-deploy-plugin, how it deploys artifacts traditionnally to a Maven repository, and how the new Maven Central Portal publication changes the approach.

This study starts with a base base project for the problem space, with 6 tests:

  1. deploy to file:target/deploy
  2. deploy at end
  3. manual upload of archive/bundle
  4. use of Sonatype Central Publishing Maven Plugin
  5. use of njord Maven Resolver extension
  6. use of JReleaser
  7. use of NXRM3

This will be followed by an evaluation based on differences:

  • use of classical pom.xml configuration of publication target for SNASPHOT and release: <project><distributionManagement><release><id>/<url>,
  • use of classical settings.xml's <server> for credentials,
  • configuration for basic md5+sha1 fingerprints and more advanced sha256+sha512,
  • preparation for Maven 4,
  • anything new or unexpected

Whatever solution is chosen, the fact that Maven Central Portal now provides an API where we upload one single archive deployment bundle help resrtying upload if anything goes unexpected.

Option 1: deploy to file:/target/staging and manual/scripted upload

Pro: Configuring is easy, then script creating a tar or zip archive and upload with UI or curl.

Limitation: scripting for upload (like it or not)

Option 2: Sonatype central-publishing-maven-plugin

Pro: Easy to configure.

Drawbacks:

  • no configuration in pom.xml distributionManagement
  • plugin has OSS license and code visible in -source.jar but not in Git, and the governance and roadmap of is not open,
  • plugin deletes maven-deploy-plugin at runtime, which confuses plugins like maven-artifact-plugin, cyclonedx-maven-plugin or spdx-maven-plugin that detect skipped modules for deployment
  • does not work for Maven 4 (runtime deletion of a plugin binding will probably be a blocker)

Option 3: njord

Pro: respects Maven‘s pom.xml distributionManagement, even hiding difference between SNAPSHOT and release, and hiding the fact that upload URL is different from download URL for Maven Central (something many tools don’t manage well)

Con: not clear how to automate publication when there are multiple stores

Having a plugin to decouple Maven's build from publication to remote gives great opportunities to better manage the staging of content during build vs the upload/publication once build is ok.

Option 4: JReleaser

Pro: does a lot

Con: does a lot, and replaces classical Maven release plugin