GeezerVison

@xerial Can you take a quick look at the changes of .github/workflows/* and *.sbt?

@komamitsu Do you still need to maintain msgpack-jackson for Jackson 2.x? If we don't have critical use cases, I'll lean to dropping Jackson 2 support as supporting both Jackson2 and 3 will be overkill for msgpack-java project.

current usage: https://mvnrepository.com/artifact/org.msgpack/jackson-dataformat-msgpack/used-by

@xerial Jackson 2 is still actively used, and Jackson 3 requires Java 17+, so not everyone can migrate yet. I think we should support both for a while.

The split module is a pragmatic way to support Jackson 3 without raising the whole project baseline. One release detail to double-check: the CI/release workflow now publishes Jackson 2 artifacts on the original JDK and msgpack-jackson3 after switching to JDK 17, but consumers will need a clear artifact-name mapping in the top-level README/release notes. Calling out jackson-dataformat-msgpack for Jackson 2 vs jackson-dataformat-msgpack-jackson3 for Jackson 3 would reduce upgrade confusion.

@hiSandog Good point. Addressed in 531d3d0

@xerial I addressed the conflict, PTAL.

BTW, it seems Universal Buffer Test has been skipped since #998 was merged.

@komamitsu Thank you for this PR — the Jackson 3 port itself looks solid, and I agree with your point that we should support both Jackson 2 and 3 for a while, since Jackson 3 requires Java 17+ and many users can't migrate yet.

Before merging, I'd like to propose restructuring the module naming. My concern with jackson-dataformat-msgpack3 is long-term: if Jackson 3 takes over Jackson 2 in the next couple of years, the unmarked name jackson-dataformat-msgpack will be stuck on the legacy version, and Jackson 3 users (the growing cohort) would eventually need a second migration from -msgpack3 back to the plain name. I'd rather put the clean name on the future from day one.

Concretely, I propose we cut msgpack-java 1.0.0 with this structure:

• jackson-dataformat-msgpack (1.x) = Jackson 3: your Jackson 3 code from this PR becomes the contents of the msgpack-jackson module. To avoid a classpath clash with the Jackson 2 artifact, the Java package moves to org.msgpack.jackson3.dataformat. Since Jackson 3 adopters are already rewriting every com.fasterxml.jackson import to tools.jackson, one more changed import costs them almost nothing — and it means both artifacts can coexist in one application for incremental migration (which was a design goal of Jackson's own tools.jackson rename).
• jackson2-dataformat-msgpack (1.x) = Jackson 2: the current msgpack-jackson code moves here unchanged, keeping the org.msgpack.jackson.dataformat package. Jackson 2 users who want to keep receiving msgpack-core updates only need a one-line artifactId change — no import changes at all. This module would be maintenance-mode (Jackson 2.x bumps and bug fixes only), documented as such in the README, to be dropped in a future major release when Jackson 2 usage fades.
• 0.9.x freezes: users who do nothing stay on jackson-dataformat-msgpack 0.9.10 and nothing breaks. We'll keep a 0.9.x branch as an escape hatch for critical fixes, but the plan is zero releases from it — this avoids maintaining two release lines with msgpack-core backports.

If dependabot/renovate proposes 0.9.x → 1.0.0 to a Jackson 2 user, it fails loudly at compile time (the old package is gone from that artifact), and the release notes will point to jackson2-dataformat-msgpack — so there's no silent breakage.

Since msgpack-java's API has been stable for a decade while sitting at 0.x, I think this transition is also the right occasion to finally signal 1.0.0.

Mechanically this reuses essentially all of your work — the Jackson 3 sources just land in msgpack-jackson with the package rename, and the JDK-conditional build exclusion you added carries over (the module still requires Java 17+ while msgpack-core and the Jackson 2 module stay on Java 8). The OSGi bundle symbolic names and export packages would be updated to match.

WDYT? If you're on board, I'm happy to help with the build.sbt / workflow changes for the restructuring.

I've opened #1012 implementing the restructuring proposed above, built on top of this PR's commits (so all the Jackson 3 port work is preserved and attributed). @komamitsu PTAL — if you prefer this direction we can continue the review there; if not, happy to discuss further here.

While enabling the module restructuring I also found that the Jackson 2 module's JUnit 5 tests have been silently skipped on main (no Jupiter test interface in the sbt build — likely related to the skipped Universal Buffer Test you noticed), and fixing that surfaced a small JsonLocation regression from #903. Both are fixed in #1012.