Migrate to Jackson 3 as jackson-dataformat-msgpack for 1.0.0; add jackson2-dataformat-msgpack

[xerial]

Summary

This PR builds on #987 (thanks @komamitsu — all the Jackson 3 port code here is from that PR) and restructures the modules for a 1.0.0 release, as proposed in #987 (comment):

Module	Artifact	Jackson	Java package	Requirements
msgpack-jackson	jackson-dataformat-msgpack (1.x)	3.x	org.msgpack.jackson3.dataformat	Java 17+
msgpack-jackson2	jackson2-dataformat-msgpack	2.x	org.msgpack.jackson.dataformat (unchanged)	Java 8+

• The unmarked artifact jackson-dataformat-msgpack targets Jackson 3.x from 1.0.0 onward; 0.9.x remains the Jackson 2.x line for users who stay put.
• The Jackson 2.x code moves to jackson2-dataformat-msgpack unchanged (same package), so migrating from 0.9.x only requires changing the artifactId. The module is maintenance-mode: Jackson 2.x bumps and bug fixes only.
• Distinct artifactIds and packages mean both artifacts can coexist on one classpath for incremental Jackson 2→3 migration.
• CI: JDK 8/11 lanes test msgpack-core + msgpack-jackson2 only; JDK 17+ lanes test everything. Release publishes core/jackson2 with JDK 8 and the Jackson 3 module with JDK 17.

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 3): 123 passed
• msgpack-jackson2: 77 passed (previously 0 executed)
• 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?