Requirements for maven central deployment

[bmarwell]

https://central.sonatype.org/pages/requirements.html

• Correct Coordinates (tracked in Project rename proposal #5
• Signing keys
• Project Name, Description and URL
• License Information Add LICENSE.txt or LICENSE or LICENSE.md #22
• Developer Information
• SCM information
• distributionManagement tag.
• add the sonatype plugin
• Create a release profile
• Take notes from https://github.com/acegi/acegi-standard-project about the GPG Key etc.

These needs to be added to the pom.xml.

Setting up the release profile

The release profile should include:

• javadoc
• java-sources
• signing

We can take a peek at projects like https://github.com/glowroot/glowroot/blob/12afc32250c96e25fa9e738fc997805b9529c368/pom.xml how they manage and implement the distribution management.

How to deploy

 # snapshot deployment
mvn clean deploy

# release deployment
mvn versions:set -DnewVersion=1.2.3
mvn clean deploy -P release

Requirements for Deployments

• Having an account at sonatype
  https://issues.sonatype.org/secure/Signup!default.jspa
• Having a GPG keypair

[maebli]

Can you deploy https://github.com/java-native/jssc/releases/tag/v2.9.1 to some maven repository distribution channel like maven central?

[bmarwell]

Hi, I am currently not very much involved, because the discussion about the reproducible build ended nowhere. That said, I never added the relevant parts to the pom.xml. Maybe @tresf or @woodrowbarlow cann add a status update? Haven't looked into it for quite a while.

[bmarwell]

@heroichornet as a workaround, you could just clone this repository and type mvn install. If you have a proxy repository set up, you could also use mvn deploy.

[tresf]

I'm not yet versed with Maven, but would be happy to accept a PR. Despite comments to the contrary, @bmhm is and always has been the project's Maven expert. 🍻

[bmarwell]

Hi @tresf, thanks for the compliments! :)

To be able to create a single invocation with all resulting jars, we still would need a completly different project structure (as far as I can tell).
However, I learned a bit of other possibilities in maven. We might also be able to compile the same project multiple times, for each desired architecture on a different build host (travis-ci for unix, etc.) and then collect all those artifacts and aggregate them in a final build.

Sadly, I do not know if I do find the time to look into this soon :( If I do, I will keep you updated!

[tresf]

@bmhm I agree that if we intend to fully automate the build process, the native libraries will need special build steps, especially those for Solaris, where CI environments are slightly harder to find.

That said, I don't think these automation steps are required for a maven release. When the rest is ready, we should be able to release to maven with our existing binaries. I cannot speak on behalf of rest of the steps.

[maebli]

Hi guys, thanks for the reply. I do have it working, but it would be cool if I could pull it directly. I understand if you don't have the time. Do I understand correctly. A PR would have to finish the tasks mentioned in the first post of this ticket?

[bmarwell]

Hi @heroichornet,

not the time is the problem. Maven central does not allow to push artifacts with a groupId where you do not own the corresponding domain name.

That said, the next major version will probably contain some other group name and package names so we can push our artifacts to maven central.

Until then, you could set up your own nexus or artifactory.

[bmarwell]

Reminder to myself
https://github.com/stefanbirkner/travis-deploy-to-maven-central?files=1