Commits
Tarun Sukhani authored 15023091aad
chore(deps): resolve vendored jars for the netty-tcnative and Hibernate bumps
Both Renovate branches just merged edit framework/dependencies.yml only,
leaving framework/lib/ holding the previous jars -- which is why their CI
went green without ever exercising a new artifact.
Ran `ant resolve -Dprune=true`: 8 jars copied, 8 pruned, a clean 1:1 swap.
netty-tcnative-classes 2.0.81.Final -> 2.0.83.Final
netty-tcnative-boringssl-static 2.0.81.Final -> 2.0.83.Final
(x5: osx-aarch_64, osx-x86_64, linux-aarch_64, linux-x86_64,
windows-x86_64)
hibernate-core 7.4.5.Final -> 7.4.7.Final
hibernate-jcache 7.4.5.Final -> 7.4.7.Final
PR #31 arrives titled "update netty to v2.0.83.final", which reads as a
4.x -> 2.x downgrade against a codebase on netty 4.2.17.Final. It is not.
netty-tcnative is the BoringSSL JNI binding and ships on its own 2.0.x
line, independent of the netty-codec/-transport/-buffer artifacts, which
this bump does not touch -- all nine stay at 4.2.17.Final. Renovate's
io.netty:** group rule simply names the PR after the artifacts it changed.
Classifying by changed files rather than by PR title is what distinguishes
the two cases.
Verified against the new jars: `ant test` green, 760 tests across 132
suites, 0 failures. Both bumps land on covered paths -- tcnative is the
TLS/ALPN native layer behind Http2FunctionalTest (3), Http3FunctionalTest
(1), Http2WebSocketFunctionalTest (6) and Http3WebSocketFunctionalTest
(5), and hibernate-core backs JpaLazyPoolTest (3). All green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>