Release artifacts to Maven Central repository

[heuermh]

In order to release artifacts to the Maven Central repository, the following should be done

• Add <plugin-management> section, Maven enforcer plugin configuration, and release profile to pom.xml
• Add <developers> section to pom.xml
• Create a new project on Sonatype OSS Nexus for groupId org.ga4gh
• Add KEYS file with public code signing keys of all developers interested in the role of release manager
• Deploy current version 0.6.0-SNAPSHOT to Sonatype OSS Nexus snapshots repository
• Manually sign and release artifacts from 0.5 and 0.5.1 releases to Sonatype OSS Nexus releases repository
• When version 0.6.0 is ready, release to Sonatype OSS Nexus releases repository and enable rsync to Maven Central repository

I am willing to take these on. Would any one else be interested in the role of release manager? @massie @fnothaft?

[heuermh]

Bump.

Meanwhile, opencb.org has had to publish GA4GH artifacts to Maven Central under their own groupId.

See http://search.maven.org/#search|gav|1|g%3A%22org.opencb.ga4gh%22%20AND%20a%3A%22ga4gh%22

[mcupak]

Bump, if I may.

How far along is this issue? We're working on the new Beacon schema release and it would be nice to propagate the artifact to Maven Central as well. I'm wondering how to go about this in a consistent way (we're using the same group ID, so I'm wondering if we can share the project on Sonatype OSS Nexus etc.).

Beacon will also very likely have a dependency on the core schemas soon. It would be nice if the artifact was in Maven Central so that we can pull it in easily.

[heuermh]

@mcupak as I said above, I'd be willing to take this on, however I have heard nothing from any working group members as far as release plans. The todo list above still looks appropriate.

[kozbo]

snip from an email from @heuermh that documents the steps we need to take next: There are still some housekeeping steps necessary before we can sync to Maven Central: Create a new project on Sonatype OSS Nexus for groupId org.ga4gh This is an administrative task; someone has to register the groupId by filing a ticket with Sonatype, and then add permission for one or more accounts to make releases under that groupId. Note that the Beacon project is also interested in releasing artifacts, so coordination will need to take place.

Add KEYS file with public code signing keys of all developers interested in the role of release manager All artifacts must be signed with an OpenPGP/GPG code signing key to be sync'd to Maven Central.

There are two approaches a project can take: 1) use personal code signing keys of project owners/release managers and take advantage of the web of trust. This is the approach taken by the Apache Software Foundation projects. 2) create and share credentials to a single project code signing key. This is the approach taken by the BDG projects, including ADAM. I am personally not in favor of this approach.

In either case, a KEYS file needs to be added to the repository with the public key(s) used to sign artifacts. Since there isn't such in the v0.6.0a5 release tag, we would have to wait for the next release.

[kozbo]

created the Sonatype Jira ticket to create the ga4gh project. We will see if they think I am enough of an owner to create the project.

[mcupak]

@kozbo The ticket looks resolved - what's the next step?

[heuermh]

• [x] Need a pull request for KEYS file @kozbo created
• [x] Distribute public key(s) to keyservers, per Sonatype Distributing Your Public Key
• [x] Complete review and merge #641
• [x] Update maven plugin versions, pull requests #662, #663
• [x] Clarify versioning (will the next release be 0.6.0, or 0.6.1, or 0.7.0, or 1.0?)
• [ ] Run release scripts to create release candidate(s) to review, starting with e.g. 0.6.0-RC1
• [ ] Once a release candidate looks ok, cut a proper 0.6.0 release

[kozbo]

KEYS file in #664

[kozbo]

Distributed key 452DCC6D

[kozbo]

Next release will be v0.6.0a6. Waiting for one more merge and then I will do the release.

[kozbo]

re-opening as this still has some work to be done. release scripts are still not working properly with the keys.

[heuermh]

@ejacox @kozbo ping me if you need any help

[fnothaft]

w00t! Thanks for pushing this through!

[heuermh]

Could this be re-opened for further discussion? I'm not sure #762 was the right approach.

[kozbo]

Reopened after discussion with @heuermh. Short term plan is

1. create first release manually
2. modify the scripts to add back in support for 2.a. ability to roll-back 2.b. add in version tags (though we do our release process differently so this code will change from the original)