Publish to Maven Central

[tomokinakamaru]

Publish to Maven Central

[bannmann]

No, that was intentional. A group ID is not meant to represent only you as an author, but a group of related artifacts. Right now, there's only one, a jar artifact with the artifact ID silverchain and type jar. But one can easily imagine more, e.g. a silverchain-api.jar, a silverchain-ui.jar etc. Also, you may at some point have another project called foo which will then usually get the io.github.tomokinakamaru.foo group ID. (edit: I forgot the .foo suffix)

[bannmann]

Yes, we're done here: my plugin works fine with this release and can now make its way to Central, as well. Thank you!

[tomokinakamaru]

Thanks for the detailed guide! It saved me a lot of time googling how to publish software :)

It's now ready (https://issues.sonatype.org/browse/OSSRH-74193?page=com.atlassian.jira.plugin.system.issuetabpanels), so I will merge PR #62 and publish to Central soon.

[tomokinakamaru]

I merged #62 and ran ./gradlew publish on the master branch. Are these all I need to do? (I guess not, but I couldn't figure out what I am missing...)

[bannmann]

Yes, there's more to do. But didn't want to explain step 2 before we're through with step 1. Also, I didn't have the time yesterday.

Here we go. Let's start with some background on versioning/publishing that only comes into play after you complete the next step, but which will remain very important for the rest of Silverchain's lifetime. (Sounds ominous, right? 😉)

Background

Immutable artifacts

First, you need to know that on Maven Central, no artifact ever gets deleted or updated. The repository maintainers enforce this rule mercilessly, and that's a good thing, because it's the only way to guarantee stability and reproducibility of downstream builds. So if my shiny new 2.0.0 was published and I realize one second later that something is wrong, it doesn't matter whether it's a small cosmetic detail or a horrible bug: the only solution is to publish a new artifact version, e.g. 2.0.1. The broken 2.0.0 will be kept; all I can do is to tell people to please not use it.

So unlike Git, which doesn't really care if you force push master or delete a tag again, things are final on Maven Central.

Version management

For Silverchain, this simply means that choosing the 0.1.0 version now means that before publishing the next time, one needs to change the version number. In fact, one should do so immediately after the publication because not doing so creates trouble for Silverchain developers: if I check out a newer master commit and rebuild locally, Gradle will (presumably) act just like Maven and happily overwrite the 0.1.0 in my local Maven repo with the altered 0.1.0.

Snapshot versions

A good way to do this is to switch to a snapshot version immediately after publishing 0.1.0. Snapshot versions represent a "fluid" state in-between proper releases. If the next (planned) release was 0.2.0, Silverchain's gradle.properties on master (and ideally everywhere else) would have version version=0.2.0-SNAPSHOT. Unlike proper releases, snapshot versions can actually be published repeatedly, e.g. daily or even after every commit (usually those from develop). In case of OSSRH, snapshots are not propagated to Maven Central. However, they can be obtained from the OSSRH snapshots repository, which is useful for downstream projects wishing to keep up with current Silverchain development.

When the time comes to release 0.2.0, you change the version property to, well, 0.2.0, then commit and push to master, then publish.

Gitflow and automation

As you may have guessed by now, both the publishing process itself and changing the version really benefits from continuous integration, automated builds and a Gitflow master/develop distinction. But let's save all that for later.

Performing the Release

Because one needs to be sure everything is fine before releasing, publishing (or "deploying" as Maven calls it) an artifact to OSSRH only puts it into a staging repository where the author can inspect the artifacts before starting the real publishing process.

As we're talking only about a harmless 0.1.0 version, IMO you don't really need to do much to check things. So just follow the instructions on Releasing the Deployment.

As part of this process, OSSRH applies some checks (e.g. artifacts having complete metadata like license, URLs etc). I think #62 did everything that's required, but I can't be sure as this is the first time I'm using Gradle for this instead of Maven. You will see the results of the checks (nearly) immediately in the UI.

If the deployment passes all checks, the artifacts will be synced to Central after a while (usually less than two hours).

[tomokinakamaru]

I pressed the release button in Nexus repository manager, but after that, I found that the artifact has the wrong (?) group ID io.github.tomokinakamaru.silverchain:

(Since I am not familiar with Maven Central, I am not sure io.github.tomokinakamaru.silverchain is wrong or not, but io.github.tomokinakamaru seems natural to me.)

Should we fix the following line and release again?

silverchain/build.gradle

Line 108 in 1e30439

def mavenGroupId = 'io.github.tomokinakamaru.silverchain'

or can we leave the group ID as it is now? I should have checked your PR more carefully before merge and release, sorry :(

[tomokinakamaru]

I see, so I didn't make a mistake (though I thought I did 😅).

Now, finally, Silverchain is on https://repo.maven.apache.org/maven2/io/github/tomokinakamaru/silverchain/silverchain/. If there is nothing more to do, please close this issue :)