Distribute Java Client API releases on Maven Central

[sammefford]

Recreating https://bugtrack.marklogic.com/27634 in github

We currently provide our own manually managed Maven repo http://developer.marklogic.com/maven2. This works for developers to get the right artifacts and dependencies. However, it's problematic in two ways: 1) A developer has to modify her POM with a new repository entry 2) Our artifacts aren't discoverable for those searching the known central repo for MarkLogic tools.

Out-of-the-box, Maven knows about its Central repo http://central.sonatype.org (and a UK mirror). There is a pretty low bar to publishing to the central repo http://central.sonatype.org/pages/requirements.html, most of which we do already. I'd like to propose for 8 that we shoot for publishing here instead of our own repo. We should maintain older versions in our own repo so as not to break any existing code.

• Sources and JavaDocs
• GPG/PGP signatures
• Dependencies
• Project metadata: Name, description, license, SCM URL, etc.

Thinking about the end-to-end development experience, I view this as a hole in the requirements. (I specified distribution via NPM https://www.npmjs.org in the Node client requirements for just this reason.)

This task covers GA major, minor, and patch releases. Distributing snapshots, for EA evaluation for example, is a separate albeit related issue.

[gvaidees]

@sammefford I think we need to make sure that the publick key id and the server where the public key id has been loaded needs to be specified in some place in our repo so that customers know how to verify the signature. I am hearing that it might be a good think to sign the pom as well. But, perhaps that is low priority.

[grechaw]

It looks like there's a process to get provisioning for the repo that has a turnaround. Was this process initiated already? It looks like we're moving with sonatype's hosting, right? http://central.sonatype.org/pages/ossrh-guide.html

[gvaidees]

@grechaw we are not doing sonatype hosting yet. @sammefford and I had a chat about what to do with the signatue, how someone would verify it etc. At this point, we are doing the minimum necessary to upload our jars to maven central. And for that we need a signature. We have generated our own key (pgp) and using that to sign the jar. Public key has been uploaded to a key server already. In 3.0-1, customers would have to use gpg to verify the signature. I believe @smefford will also have the publick key Id available somewhere in github so that customers can verify the signature. Hope this makes sense.

And I am not sure about the turnaround time from mvn central folks to host the jars. Good question though.

[grechaw]

It seems to me that sonatype handles the free hosting for open source projects on maven central. The process for getting that relationship going is on the link above. It seems there's a one-time setup request that must be done, after which one has access to deploy artifacts in an automated fashion. They quote the turnaround for one-time setup as "often hours, usually less than two days".

I'm sure you can understand, given we require this release for samplestack's, that I might wonder if this has already occurred -- I'd expect to see a link to sonatype's Jira system.

[sammefford]

We're close on this. My bad on thinking that since http://central.sonatype.org/pages/requirements.html didn't mention a requirement to use Sonatype, we could somehow deploy to Maven Central without Sonatype. Now it appears clear to me that the only option to deploy to Maven Central is via Sonatype / OSSRH / Nexus.

Our JIRA ticket is created and as I understand it they will use it to prepare us to deploy to maven central. Please feel free to create a Sonatype JIRA account and login if you want to "watch" the ticket (subscribe to notifications). That will give you the most immediate feedback on the status.

[popzip]

Are we on the step that says "less than 2 business days"? When did we trigger that?

[gvaidees]

Yesterday