Publish packages in Maven Central

[mk868]

The publishing to maven central topic has happened several times before (#7 #6).

Why this proposal again?
Libraries that are in Maven Central cannot have dependencies on libraries in other repositories (like JitPack).
So if any library located in Maven Central wants to use java-multibase then it simply cannot.

So, I propose to publish library to the Maven Central.
I did such publishing myself some time ago and the process turns out to be simple.
Of course I want to support with that, I can create an action on GitHub with the deployment (just a few simple steps in the .yml file) and show how it works on my forked repo.

What do you think?

[ianopolous]

Sure that would be great, thanks!

[vorburger]

The thing to keep in mind here is that someone needs to own and responsibly manage, and possibly in the future share with other maintainers, the PGP private key for deploying into io.ipfs.multibase on Maven Central. I'm not sure what the best way is to manage that.

[mk868]

We can generate a new PGP key, only for deployment to Maven Central, and store the private key in the project's secret variables.
Then the deployment process will be done by GitHub action by users with the necessary permissions.
With that we will reduce the possibility of private key leakage.

[mk868]

Worth to note:
@vorburger You mentioned about io.ipfs.multibase groupId on Maven Central.

For compatibility reasons we may prefer to stay with com.github.multiformats groupId, then the migration path from JitPack to Maven Central would be straightforward for users/projects - most won't notice the difference that the library was loaded from Maven Central and not from JitPack.
Also we would avoid the situation where users have both io.ipfs.multibase and com.github.multiformats artifacts in the class path.
However, as of April 2021, com.github.* group ids will not be accepted.

So, to publish java-multibase to the Maven Central we will need to change the groupId...

To mitigate the problem with duplicated artifacts in the classpath, we can release a new dummy (.jar without any .class files) version of the com.github.multiformats artifact on jitpack.io with single dependency: io.ipfs.multibase.

[mk868]

To summarize, migrating libraries from JitPack (which may not be so reliable) to Maven Central will require a change in the groupId.

The proposed changes are outlined in the table below:

Project	Current groupId:artifactId	Proposed groupId:artifactId
java-cid	com.github.ipld:java-cid	io.ipfs.multiformats:cid
java-multibase	com.github.multiformats:java-multibase	io.ipfs.multiformats:multibase
java-multiaddr	com.github.multiformats:java-multiaddr	io.ipfs.multiformats:multiaddr
java-multihash	com.github.multiformats:java-multihash	io.ipfs.multiformats:multihash

As mentioned earlier, we can simplify the migration by redirecting JitPack artifacts to Maven Central ones using an empty artifact with a dependency, e.g., redirecting com.github.multiformats:java-multibase to io.ipfs.multiformats:multibase.

However, implementing this change will require a decision at a higher project level.

[vorburger]

Just noticed https://mvnrepository.com/artifact/com.github.multiformats/java-multibase/1.1.1 by https://scijava.org

[vorburger]

To summarize, migrating libraries from JitPack (which may not be so reliable) to Maven Central will require a change in the groupId.

It looks like someone managed to publish without changing the groupId, see https://mvnrepository.com/artifact/com.github.multiformats.

[vorburger]

To summarize, migrating libraries from JitPack (which may not be so reliable) to Maven Central will require a change in the groupId.

It looks like someone managed to publish without changing the groupId, see https://mvnrepository.com/artifact/com.github.multiformats.

No, that's incorrect; see multiformats/java-multihash#24 (comment).

[vorburger]

The proposed changes are outlined in the table below:

One thought on this: There is also the https://github.com/ipfs-shipyard/java-ipfs-http-client. And that's not multiformats.

So should we move to io.ipfs.multiformats:* or simply io.ipfs:* ? -- Or should we then go for io.multiformats:*? I actually like that! Then java-ipfs-http-client should (eventually) be io.ipfs:http-client? Seems logical and consistent, to me.

@cstamas @ianopolous @mk868 thoughts? I've taken the liberty to raise #55 accordingly - for discussion.

[cstamas]

I agree with all of this, but this is beyond me, as explained here:
ipfs-shipyard/java-ipfs-http-client#276