[dependabot]

Bumps sh.stubborn.contract from 0.1.3 to 0.2.0.

Release notes

Sourced from sh.stubborn.contract's releases.

v0.2.0

Highlights

The consumer BOM no longer overrides Spring Boot

stubborn-contract-dependencies now manages only Stubborn Contract's own artifacts, plus the libraries Spring Boot does not manage — WireMock and REST Assured. Everything else (Netty, Tomcat, Artemis, ZooKeeper, FreeMarker, httpclient5, icu4j, plexus-utils …) is left to whichever platform BOM you import.

Before this release the BOM also carried the version pins Stubborn uses for its own CVE gate. Those pins are correct on the day they are cut and wrong a month later: imported ahead of spring-boot-dependencies they silently replaced Boot's managed versions, so a consumer on a newer Boot patch could be quietly downgraded by us — with Boot 4.1 that meant a spring-boot-starter-jetty application failing to start. The pins have moved into Stubborn's own reactor, where they still gate our build and no longer leak into yours.

Fixes stubborn-sh/stubborn#142.

One deliberate exception: Jetty

wiremock-jetty12:3.13.2 is built against Jetty 12.0 / ee10, and spring-boot-dependencies version-manages every org.eclipse.jetty:* artifact — including the ee10 jars WireMock drags in — to 12.1.x, where the APIs it calls no longer exist. The stub server then dies on:

NoSuchMethodError: org.eclipse.jetty.util.component.Environment.ensure(java.lang.String)

There is no version to pin instead: no ee10 release works against Jetty core 12.1, and 3.13.2 is the newest wiremock-jetty12 on Maven Central. WireMock's shaded standalone distribution was tried as the way out and does not work either — it relocates Handlebars, so Stubborn's own response-template helpers cannot register with it.

So the BOM still manages Jetty 12.0.37, and only Jetty. The consequence is stated plainly rather than hidden: if you import this BOM, a spring-boot-starter-jetty application runs on Jetty 12.0.x rather than Boot's 12.1.x. If that matters more to you than the stub runner, exclude the org.eclipse.jetty entries when you import. The pin goes away as soon as WireMock publishes a stub server built against Jetty 12.1/ee11.

Upgrading from 0.1.x

If you relied on the BOM to pin a third-party library, pin it yourself — or let your platform BOM do it. Import order no longer matters for anything except Stubborn's own modules, WireMock, REST Assured and Jetty.

The case most likely to bite: Spring Cloud Stream. Spring Cloud ships its own release train, so spring-boot-dependencies does not manage spring-cloud-stream and this BOM deliberately no longer does either. If you declare it without a version, import the train

... (truncated)

Commits

• 0e6d7d1 Release 0.2.0
• 5c5bce6 build: restore the Jetty pin in the consumer BOM, and drop the shaded stub ru...
• 43e749f build: clear the OWASP gate on the handlebars.js vendored in handlebars.java ...
• c314034 build(deps): bump actions/setup-java from 6.0.1 to 6.1.0 (#242)
• 1f707dd build(deps): bump io.quarkus:quarkus-test-common from 3.38.1 to 3.40.1 (#241)
• 296e40c build(deps): bump tomcat.version from 11.0.26 to 11.0.27 (#240)
• 8eb5b66 build: add a standalone stub runner starter, and repurpose the Jetty one onto...
• a7f1288 build: stop managing Spring Boot's versions from the consumer BOM (#243)
• 8a0bc4f build(deps): bump the rest-assured group across 1 directory with 2 updates (#...
• cdbaf1d build(deps-dev): bump org.apache.maven.plugins:maven-failsafe-plugin (#237)
• Additional commits viewable in compare view

[github-actions]

JaCoCo Code Coverage

Overall Project	93.21%	✨

There is no coverage information present for the Files changed

[rashidi]

@dependabot rebase