feat: Support for floci

[Mendred]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Added floci as aws emulator

💡 Motivation and Context

Localstack changed its license model and pricing, so I added floci as supported emulator

💚 How did you test it?

Added a test with a custom floci docker-compose file

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• I updated reference documentation to reflect the change
• All tests passing
• No breaking changes

🔮 Next steps

[MatejNedic]

Hello @Mendred,

Thanks for the PR. I think we should introduce Floci as an alternative rather than a replacement for LocalStack.

Before referencing it in the documentation, I’d like to review the Floci code, as it’s quite new and doesn’t yet have an established track record.

I’ll try to go through it this week, especially since I noticed it’s written in Quarkus.

[Mendred]

@MatejNedic
Thank you for your reply! I added floci as supported aws emulator and renamed the classes from localstack to a more generic name. It wasn't intended as a replacement, but merely as an extension, since the idea is to be able to use both technologies.

Floci is new, but it has a very active community, and I'm looking forward to seeing the results of your review.

[MatejNedic]

Hey @Mendred,

I took some time to look into the project, and I really like the native executable packaging and the potential for a smaller footprint.

That said, I’d prefer to hold off on integrating it for now. The project is still very new, and I noticed a high volume of incoming PRs and rapid changes, with signs that some contributions may be AI assisted.

From a maintainer perspective, adding support for an emulator also means implicitly trusting its release process and distributed artifacts (e.g., Docker images). At this stage, that introduces a supply chain risk we should be cautious about until the project matures and establishes itself over period of time.

This isn’t a rejection of the idea, I think it’s promising, and I am personally interested in contributing to Floci. Once the project has had more time to mature and prove itself, I’d be fully supportive of revisiting this and moving forward with integration. I would also add to this PR support for ServiceConnection and Spring Cloud AWS Testcontainers package check -> LocalstackAwsClientFactory.

Appreciate your work on this let's leave PR open and revisit it sometimes in closer future.

[Mendred]

Hello @MatejNedic ,

Thank you very much for your detailed response. Floci has potential as an open-source alternative to LocalStack, and I understand that the PR won’t be accepted right away since Floci is still very new.

I’m glad that Floci’s potential is being recognized and that the possibility of implementing it in Spring Cloud AWS in the future hasn’t been ruled out.

[Mendred]

@MatejNedic

I added the testcontainers-floci support

[Mendred]

Hello @MatejNedic ,
I updated the PR with a new testcontainers-floci version and support for the docker image floci/floci. It was renamed lately.

[Mendred]

@MatejNedic I removed the old name of the image and merged main into my branch. its ready to merge now. Thank you for your approval.

[klach-ocado]

Perspective of someone who imports Spring Cloud AWS BOM to his dependency management: This pollutes dependency management as it's required only for tests here. The property with version could be used directly where the dependency is needed, or a limited <dependencyManagement> section can be added only to the necessary module. As an example, Spring Boot has spring-boot-dependencies (maintained for users) and spring-boot-internal-dependencies (maintained for them) modules.

EDIT I see there is <dependencyManagement> in top-level pom.xml - that may offer what's needed.

[ThomasVitale]

Could it be an idea having floci in its own module? If I understood correctly, this dependency config means that I would get both the Testcontainers Localstack and Testcontainers Floci dependencies in my classpath if I include spring-cloud-aws-testcontainers. Did I understand that right? If that's how it works, it would limit the re-usability of this module.

For example, I publish a Floci Dev Service for Spring Cloud AWS which currently depends only on Testcontainers Floci and defines its own ConnectionDetails implementation. It would be nice if I could re-use the same ConnectionDetails for Floci defined here. But if LocalStack is in the same module, that's not gonna be an option for the Arconia Framework due to the non-OSS license and classpath pollution (more info on how the Dev Service works with Spring Cloud AWS here).

If a separate module is not desired, then at least the localstack dependencies could be marked as optional? (same approach used by Spring Boot and Spring AI)

[MatejNedic]

Hey @Mendred ,

Thanks so much for the PR! I made a few changes directly because I'd like to release 4.1.0 as soon as possible. Initially, I was planning to handle the BOM management in a separate PR, but in the end I committed the changes directly to your PR.

I wanted to get the release out this week and include Floci, and since this PR had been open for a few months, I wasn't sure how quickly you'd be able to respond. That was the only reason I committed directly instead of leaving comments and waiting for updates. Thanks again for your contribution!

Looking forward to seeing more PRs from you in the future :)

[Mendred]

Hey @MatejNedic,

thank you for your message. I think this won't be my last contribution :-)
I made a quick fix, because testcontainers-localstack is now optional and it was missing in the sample module.
I was about to replace LocalStack with Floci everywhere, but I'll do that in a later pull request since you want to release 4.1.0 as soon as possible.