From my humble point of view the ServiceConnection API does, at least for test purposes, what java-cfenv-boot achieves on a cloud platform through EnvironmentPostprocessors.
I would, thus, suggest that the API be promoted to a non-test library, somewhere it makes sense. Then the cfenv-boot library (and any cloud platform) can be smoothly integrated. This part might probably end up in the Spring Cloud family, I would guess.
Is this worth it?
Comment From: philwebb
I assume you're talking about @ServiceConnection in the org.springframework.boot.testcontainers.service.connection package which is shipped in the spring-boot-testcontainers jar? If so, that code is quite tied to Testcontainers and we wouldn't want to use it in java-cfenv.
We do, however, have shared code that both @ServiceConnection and our Docker Compose support use (mainly classes in the org.springframework.boot.autoconfigure.service.connection package). This is the code we expect project like java-cfenv to use.