GeezerVison

Fixes a packaging problem I introduced in #987.

JmhPlugin adds jmh-core, jmh-generator-bytecode and jmh-generator-reflection to libraryDependencies without a configuration. Since #987 enabled it on msgpack-jackson3, which is published, those three become compile dependencies of org.msgpack.jackson3:jackson-dataformat-msgpack and are inherited by every consumer along with jopt-simple, commons-math3 and asm:

<dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-core</artifactId><version>1.37</version></dependency>
<dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-generator-bytecode</artifactId><version>1.37</version></dependency>
<dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-generator-reflection</artifactId><version>1.37</version></dependency>

The released org.msgpack:jackson-dataformat-msgpack:0.9.11 POM has no such entries.

Fix

Move msgpack-jackson3/src/jmh into a new msgpack-jackson3-benchmark project with publish / skip := true that depends on msgpack-jackson3, and drop JmhPlugin from the published module. This is the layout sbt-jmh's README asks for, since the generator needs a project of its own and the benchmark subproject should not be published.

Verification

• msgpack-jackson3/makePom: msgpack-core and jackson-databind are the only compile-scope dependencies left, alongside the usual test-scoped entries
• msgpack-jackson3/libraryDependencies: no JMH at all
• msgpack-jackson3-benchmark/Jmh/compile: generator processes 11 classes, compiles 29 generated sources
• test: msgpack-core 193, msgpack-jackson 77, msgpack-jackson3 123
• jcheckStyle, scalafmtCheckAll, scalafmtSbtCheck: clean

The benchmark project is aggregated into the root next to msgpack-jackson3. Note that src/jmh is not compiled by test in either layout, so CI does not verify the benchmarks build.