Repository navigation
Releases in lockstep #48
Description
Seems we will need to do this, but there is a problem: I had to remove v prefixes from version as it caused issues:
Caused by: java.lang.IllegalArgumentException: error: bad value for --module-version option: 'v1.3.0-SNAPSHOT'
at com.sun.tools.javac.main.Arguments.error (Arguments.java:902)
at com.sun.tools.javac.main.Arguments.doProcessArgs (Arguments.java:384)
at com.sun.tools.javac.main.Arguments.processArgs (Arguments.java:348)
at com.sun.tools.javac.main.Arguments.init (Arguments.java:247)
at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:191)
at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:119)
at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:68)
at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:125)
Activity
cstamas commentedon Jan 21, 2026
@ianopolous
cstamas commentedon Jan 21, 2026
Seems versions with leading
vviolate JPMS "module version" spec?https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L957-L1003
cstamas commentedon Jan 21, 2026
Why was this
vprefix added to versions in the first place? I mean, it seems constant and does not add (nor take) anything from selectivity or ordering... but sadly JPMS dislikes it.cstamas commentedon Jan 21, 2026
Also, my feeling is that all these tiny projects would benefit a lot from some common parent POM (as they are basically 100% same thing sans dependencies).
Where could be craft one for them? But I personally think pushing them all together into one reactor would really be the simplest...
ianopolous commentedon Jan 21, 2026
It was just a convention from protocol labs ecosystem. Fine to remove it
cstamas commentedon Jan 21, 2026
Ok, the
vprefix will be removed (clashes withjavac --module-versionoption as can be seen above.Then we need
1.3.0release of java-multibase from master, I guess? What are plans, where to publish? jitpack as before or Central?ianopolous commentedon Jan 22, 2026
I've pushed 1.3.0 and triggered jitpack
cstamas commentedon Jan 22, 2026
multiformats/java-multihash#54 read for review and possible merge, to be followed by git-blame ignore...
cstamas commentedon Jan 22, 2026
last PR for multihash multiformats/java-multihash#55 and I suggest multiformats/java-multihash#52 as well, and then release 1.3.7 (or 1.4.0? I don't know what changes are)
ianopolous commentedon Jan 22, 2026
multihash 1.4.0 is out now
cstamas commentedon Jan 22, 2026
next ipld/java-cid#45
cstamas commentedon Jan 22, 2026
ipld/java-cid#46 is last and a release, 1.4.0?
ianopolous commentedon Jan 22, 2026
I just noticed cid has the same name issue
ianopolous commentedon Jan 22, 2026
and multihash too
cstamas commentedon Jan 22, 2026
bummer, sorry for that.... what now? should we do .1 releases to fix this? As far maven and JAR goes, it really does not matter ad
project.nameis mostly used in reporting...1 remaining item
ianopolous commentedon Jan 22, 2026
If maven doesn't care. I say leave it.
cstamas commentedon Jan 22, 2026
merge them, and will get out on next .1 release, issues, git, these are important metadata (not only for consumers, but for anyone curious "from where this comes" for example)
cstamas commentedon Jan 22, 2026
If everything ok, ipld/java-cid release, 1.4.0?
ianopolous commentedon Jan 22, 2026
Ok that's out now
cstamas commentedon Jan 22, 2026
Ok, next is multiformats/java-multiaddr#33
cstamas commentedon Jan 22, 2026
And hopefully last multiformats/java-multiaddr#34
cstamas commentedon Jan 22, 2026
And if all fine, java-multiaddr 1.5.0 release? And if that happened, this issue can be closed and we are back to https://github.com/ipfs-shipyard/java-ipfs-http-client
ianopolous commentedon Jan 22, 2026
Okay that's out now too. Thanks for all your help.
cstamas commentedon Jan 23, 2026
Ok, we seems to be fine, few remarks:
mvn installwill replace the JAR in local repo, and given it is release version, will never figure out it is altered locally (pull the "real one" from remote). Hence, post release step by adding +.1-SNAPSHOT is recommended.Aside of these, I say is fine to close this issue, we had the release spree done successfully, next pending change is
ipfs-shipyard/java-ipfs-http-client#269
ianopolous commentedon Jan 23, 2026
Thanks, I've done that. I view that as a deficiency of maven's design.
cstamas commentedon Jan 23, 2026
Me too, but we cannot fix that even in Maven 4 (as it must offer Maven 3 compat)...
My thoughts about this topic https://maveniverse.eu/blog/2025/11/09/maven-local-repository/
cstamas commentedon Jan 23, 2026
The "fix" can be split repository (that keeps separately cached and locally-built artifacts), but as we saw, split repository is "too invasive". Hence I did Mimir + regular local repo nuking is fix for me.
ianopolous commentedon Jan 23, 2026
What are your thoughts on bazel?
cstamas commentedon Jan 23, 2026
I never used Bazel on any daily basis, I don't have much knowledge about it. This is more a @vorburger question IMO.