S3Mock is incompatible with Spring Boot 3.2.x and Spring Framework 6.x

[jthurne]

The way parameter names are detected (for annotations such as @PathVariable) changed in Spring Boot 3.2.0 and Spring Framework 6.x (see Parameter Name Discovery in the Spring Boot 3.2 Release Notes).

Unfortunately, this causes the latest version of S3Mock to be incompatible with Spring Boot 3.2.x and Spring Framework 6.x. Attempting to use S3Mock with Spring Boot 3.2.x results in errors similar to:

java.lang.IllegalArgumentException: Name for argument of type [java.lang.String] not specified, and parameter name information not available via reflection. Ensure that the compiler uses the '-parameters' flag.

Thankfully, this is very easy to fix. The Java compiler needs to be configured to use the -parameters flag, which causes the compiler to include the necessary metadata Spring needs to detect the parameter names.

Using Maven, this can be done by adding <parameters>true</parameters> to the configuration section of the maven-compiler-plugin. See Parameter Name Retention in Upgrading to Spring Framework 6.x for a more complete example.

I have done this with a local checkout of S3Mock, and I have confirmed it works.

[afranken]

@jthurne thanks, I'll try to release a new version today, wanted to do that for a couple of weeks now anyway...

However, please note that a direct Java integration with the S3Mock always has the risk of bringing dependency incompatibilities into your project.
While I try to keep everything current and compatible, the best practice to use S3Mock in your project is via Docker:
https://github.com/adobe/S3Mock#s3mock-docker

[jthurne]

Awesome, thank you @afranken!

However, please note that a direct Java integration with the S3Mock always has the risk of bringing dependency incompatibilities into your project.
While I try to keep everything current and compatible, the best practice to use S3Mock in your project is via Docker:
https://github.com/adobe/S3Mock#s3mock-docker

Noted. We do strive to use Docker for these sorts of things when we can, but there are two drawbacks:

1. Spinning up docker containers tends to be slower than spinning up an "in process" server within a test. On a project with tens of thousands of tests, these small amounts of time add up quickly.

2. Unfortunately, on our CI setup, Docker is somewhat unreliable, and relying on Docker containers introduces instability into our build.

Hopefully over time, Docker will get faster and more reliable and we'll be able to leverage it more for this sort of thing in the future.

In any case, your quick response is very much appreciated! Thank you for all you do for the community.

[afranken]

@jthurne I just released 3.3.0 which depends on Spring Boot 3.2.1 :)