Add Jackson 3 support as org.msgpack.jackson3:jackson-dataformat-msgpack

[xerial]

Summary

This PR builds on #987 (thanks @komamitsu — all the Jackson 3 port code here is from that PR) and adds Jackson 3 support as a new artifact, keeping the existing Jackson 2 artifact untouched.

Following the review discussion (JLBP-6), the Maven coordinates and the Java package are renamed together, mirroring Jackson's own 2→3 groupId change (com.fasterxml.jackson.dataformat → tools.jackson.dataformat):

Module	Jackson	groupId	artifactId	Java package	Requirements
msgpack-jackson	2.x	org.msgpack	jackson-dataformat-msgpack	org.msgpack.jackson.dataformat	Java 8+
msgpack-jackson3	3.x	org.msgpack.jackson3	jackson-dataformat-msgpack	org.msgpack.jackson3.dataformat	Java 17+

• Jackson 2 users need no changes: coordinates, package, and code are identical to the current 0.9.x line (JLBP-6 Case 1 for existing users). The module is maintenance-mode: Jackson 2.x bumps and bug fixes only.
• Jackson 3 is a new artifact under the org.msgpack.jackson3 groupId with a new Java package (JLBP-6 Case 4: Maven ID and Java package renamed together). No two artifacts ever share fully-qualified class names, so both can coexist on one classpath for incremental Jackson 2→3 migration, and dependency resolution can never silently swap one for the other.
• No 1.0.0 version bump is needed; the 0.9.x line continues.
• CI: JDK 8/11 lanes test msgpack-core + msgpack-jackson (Jackson 2); JDK 17+ lanes test everything. Release publishes core/jackson (Jackson 2) with JDK 8 and msgpack-jackson3 with JDK 17.
• sbt note: both subprojects share the artifactId jackson-dataformat-msgpack, so the Jackson 3 project overrides outputPath to keep sbt 2 build output directories from overlapping.

Pre-existing test issues found and fixed along the way

1. The Jackson 2 module's JUnit 5 tests have been silently skipped on main: sbt has no Jupiter test interface, so ./sbt msgpack-jackson/test detects 0 tests and CI passes vacuously. Added sbt-jupiter-interface so they actually run (77 tests).
2. MessagePackDataformatTestBase used JUnit 4 @Before/@After on JUnit 5 tests, so setup never ran → converted to @BeforeEach/@AfterEach.
3. With the tests running again, one real regression surfaced: Fix Jackson deprecation warnings in MessagePackFactory #903 replaced a deprecated JsonLocation constructor in MessagePackParser and silently dropped the byte offset reported via getColumnNr(). Restored using the non-deprecated 5-arg constructor, matching the Jackson 3 port's behavior (byte offset as columnNr).

Test results

• msgpack-core: 193 passed
• msgpack-jackson (Jackson 2): 77 passed (previously 0 executed)
• msgpack-jackson3 (Jackson 3): 123 passed
• checkstyle and scalafmt clean

Closes #933. Supersedes #987 (includes all of its commits).

🤖 Generated with Claude Code

https://claude.ai/code/session_014ZZUaHusAjVx6SNu4sA42s

[komamitsu]

@xerial Thanks for building on the PR. I understand the goal of giving Jackson 3 the unqualified jackson-dataformat-msgpack artifact ID, but I have three concerns.

1. jackson2-dataformat-msgpack and jackson-dataformat-msgpack:0.9.x publish classes with the same fully qualified names. Maven and Gradle treat them as unrelated artifacts, so both JARs can appear on the classpath. This is a realistic case because fluency-fluentd:2.7.4 still has a runtime dependency on jackson-dataformat-msgpack:0.9.11.

   Whichever org.msgpack.jackson.dataformat.MessagePackFactory is found first is loaded. If jackson2-dataformat-msgpack later adds a method, for example a new option accompanying a bug fix, an application could compile against it and then fail with NoSuchMethodError because the 0.9.x class was loaded. Even without any API change, a bug fix could be silently ignored for the same reason.

   This is JLBP-6 Case 2, marked "NEVER DO THIS":

   https://jlbp.dev/JLBP-6

2. jackson-dataformat-msgpack changes from Jackson 2 with org.msgpack.jackson.dataformat in 0.9.x to Jackson 3 with org.msgpack.jackson3.dataformat in 1.0.0.

   Because both versions have the same Maven ID, only one can remain after dependency resolution. An application directly using 1.0.0 with Fluency will not retain Fluency's 0.9.11 dependency. Fluency's compiled code instantiates org.msgpack.jackson.dataformat.MessagePackFactory, which is absent from 1.0.0, causing NoClassDefFoundError at runtime. Its runtime-scoped dependency means ordinary application compilation will not detect this.

   This is JLBP-6 Case 3. The issue is not simply that 1.0.0 contains breaking changes, but that the Jackson 2 and Jackson 3 packages cannot coexist under the same Maven ID.

3. jackson2-dataformat-msgpack does not follow the established jackson-dataformat-* naming pattern.

Could we instead give Jackson 3 a new group ID?

	groupId	artifactId	package
Jackson 3	org.msgpack.jackson3	jackson-dataformat-msgpack	org.msgpack.jackson3.dataformat
Jackson 2	org.msgpack	jackson-dataformat-msgpack	org.msgpack.jackson.dataformat

This is JLBP-6 Case 4: the Maven ID and Java package are renamed together. Existing Jackson 2 users do not need to change coordinates, both modules keep the jackson-dataformat-* name, and the two can coexist.

Jackson used a similar structure for its XML module:

• Jackson 2: com.fasterxml.jackson.dataformat:jackson-dataformat-xml
• Jackson 3: tools.jackson.dataformat:jackson-dataformat-xml

Would this structure work here?

[xerial]

Good catch. We need to add a new group ID to fully isolate modules. In that sense, a 1.0.0 version bump is unnecessary. A tricky part is that users need to specify a different group ID for msgpack-core and jackson3, but jackson3 is a new module, so this group naming should be acceptable.

[xerial]

Restructured the PR as discussed (98e90f5):

	groupId	artifactId	package
Jackson 3	org.msgpack.jackson3	jackson-dataformat-msgpack	org.msgpack.jackson3.dataformat
Jackson 2	org.msgpack	jackson-dataformat-msgpack	org.msgpack.jackson.dataformat (unchanged)

The Jackson 2 module is back at msgpack-jackson/ with its original coordinates and code — existing 0.9.x users need no changes, and there is no jackson2-dataformat-msgpack artifact anymore. Jackson 3 lives in msgpack-jackson3/ as a new artifact (JLBP-6 Case 4: Maven ID and Java package renamed together), so both can coexist on one classpath. The 1.0.0 version bump is dropped; the 0.9.x line continues. PR description updated accordingly.