Change com.github.tomakehurst:wiremock-jre8-standalone coordinates to allow migration to version 3.0.0+

[helpermethod]

With Wiremock 3.0.0, groupId and artifactId have changed from

com.github.tomakehurst:wiremock-jre8-standalone

to

org.wiremock:wiremock-standalone

By adapting the coordinates, you should still get automated dependency updates.

I can provide a PR if applicable.

[marcingrzejszczak]

Hey, have the packages changed too? Cause if they did that's a breaking change.

[helpermethod]

At least not yet, though some APIs have been deprecated

https://github.com/wiremock/wiremock/tree/master/src/main/java/com/github/tomakehurst/wiremock

[helpermethod]

Ah, but a few classes have been moved, like

https://github.com/wiremock/wiremock/tree/master/src/main/java/com/github/tomakehurst/wiremock/extension/ResponseTemplateTransformer.java

to

https://github.com/wiremock/wiremock/tree/master/src/main/java/com/github/tomakehurst/wiremock/extension/responsetemplating/ResponseTemplateTransformer.java

And the instantiation of ResponseTemplateTransformer changed

wiremock/wiremock#2349

[marcingrzejszczak]

I see. I'll have to think about it but actually we could theoretically support both versions. These are 2 separate jars, we can have 2 different conditionals on classes etc. Do we know if the stub JSON produced by WireMock 3 is compatible with WireMock 2 ?

[helpermethod]

According to the docs the JSON output/API should be the same.

[helpermethod]

Doesn't spring-cloud-contract package Wiremock? So upgrading to the lastest version should be transparent to the user, right?

[marcingrzejszczak]

We're in touch with @oleg-nenashev to add support for WireMock 3. We'll keep everyone posted in this issue

[oleg-nenashev]

The upgrade is expected to be mostly transparent, but we need to do some integration testing. The update is unlikely to be just a dependency groupId and artifactId change, we have quite a lot of API changes

[yeikel]

I just want to pass by to mention that CVE-2023-44487 is currently impacting the 2.x version (even if it is not exploitable given that this is a test dependency) .

See https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/