Skip to content

Releases in lockstep #48

Description

@cstamas

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

  1. cstamas commented on Jan 21, 2026

    @cstamas
    ContributorAuthor
  2. cstamas commented on Jan 21, 2026

    @cstamas
    ContributorAuthor
  3. cstamas commented on Jan 21, 2026

    @cstamas
    ContributorAuthor

    Why was this v prefix 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.

  4. cstamas commented on Jan 21, 2026

    @cstamas
    ContributorAuthor

    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...

  5. ianopolous commented on Jan 21, 2026

    @ianopolous
    Member

    It was just a convention from protocol labs ecosystem. Fine to remove it

  6. cstamas commented on Jan 21, 2026

    @cstamas
    ContributorAuthor

    Ok, the v prefix will be removed (clashes with javac --module-version option as can be seen above.

    Then we need 1.3.0 release of java-multibase from master, I guess? What are plans, where to publish? jitpack as before or Central?

  7. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    I've pushed 1.3.0 and triggered jitpack

  8. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    multiformats/java-multihash#54 read for review and possible merge, to be followed by git-blame ignore...

  9. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    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)

  10. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    multihash 1.4.0 is out now

  11. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor
  12. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    ipld/java-cid#46 is last and a release, 1.4.0?

  13. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    I just noticed cid has the same name issue

  14. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    and multihash too

  15. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    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.name is mostly used in reporting...

  16. 1 remaining item

  17. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    If maven doesn't care. I say leave it.

  18. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    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)

  19. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    If everything ok, ipld/java-cid release, 1.4.0?

  20. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    Ok that's out now

  21. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor
  22. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor
  23. cstamas commented on Jan 22, 2026

    @cstamas
    ContributorAuthor

    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

  24. ianopolous commented on Jan 22, 2026

    @ianopolous
    Member

    Okay that's out now too. Thanks for all your help.

  25. cstamas commented on Jan 23, 2026

    @cstamas
    ContributorAuthor

    Ok, we seems to be fine, few remarks:

    • I see @ianopolous left all POMs with release version. This is dangerous and not recommended as if someone works on the packages, mvn install will 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.
    • I messed up some metadata for some package (copy pasta error), fixes are merged and will go out on next .1 release of corresponding packages

    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

  26. ianopolous commented on Jan 23, 2026

    @ianopolous
    Member

    Thanks, I've done that. I view that as a deficiency of maven's design.

  27. cstamas commented on Jan 23, 2026

    @cstamas
    ContributorAuthor

    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/

  28. cstamas commented on Jan 23, 2026

    @cstamas
    ContributorAuthor

    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.

  29. ianopolous commented on Jan 23, 2026

    @ianopolous
    Member

    What are your thoughts on bazel?

  30. cstamas commented on Jan 23, 2026

    @cstamas
    ContributorAuthor

    I never used Bazel on any daily basis, I don't have much knowledge about it. This is more a @vorburger question IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions