You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
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.
Activity
ianopolous commentedon Nov 29, 2024
Sure that would be great, thanks!
vorburger commentedon Jan 4, 2025
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.multibaseon Maven Central. I'm not sure what the best way is to manage that.mk868 commentedon Jan 7, 2025
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 commentedon Jan 7, 2025
Worth to note:
@vorburger You mentioned about
io.ipfs.multibasegroupId on Maven Central.For compatibility reasons we may prefer to stay with
com.github.multiformatsgroupId, 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.multibaseandcom.github.multiformatsartifacts in the class path.However, as of April 2021,
com.github.*group ids will not be accepted.So, to publish
java-multibaseto 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.multiformatsartifact on jitpack.io with single dependency:io.ipfs.multibase.mk868 commentedon Jan 15, 2025
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:
com.github.ipld:java-cidio.ipfs.multiformats:cidcom.github.multiformats:java-multibaseio.ipfs.multiformats:multibasecom.github.multiformats:java-multiaddrio.ipfs.multiformats:multiaddrcom.github.multiformats:java-multihashio.ipfs.multiformats:multihashAs 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-multibasetoio.ipfs.multiformats:multibase.However, implementing this change will require a decision at a higher project level.
vorburger commentedon Feb 28, 2025
Just noticed https://mvnrepository.com/artifact/com.github.multiformats/java-multibase/1.1.1 by https://scijava.org
vorburger commentedon Mar 8, 2026
It looks like someone managed to publish without changing the
groupId, see https://mvnrepository.com/artifact/com.github.multiformats.vorburger commentedon Mar 8, 2026
No, that's incorrect; see multiformats/java-multihash#24 (comment).
vorburger commentedon Mar 8, 2026
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 simplyio.ipfs:*? -- Or should we then go forio.multiformats:*? I actually like that! Thenjava-ipfs-http-clientshould (eventually) beio.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 commentedon Mar 10, 2026
I agree with all of this, but this is beyond me, as explained here:
ipfs-shipyard/java-ipfs-http-client#276