Better name for @DockerRequired

[rhusar]

Let's find a better name for @DockerRequired. We in reality require any containerization software that is compatible with Testcontainers (their explicit wording 'Docker-API compatible container runtime'), thus including podman. Random ideas:

• RequiresContainerRuntime
• ContainerRuntimeRequired
• ContainersRequired
• RequiresContainers
• ContainerizationRequired
• RequiresContainerization
• RequiresDockerAPICompatibleRuntime
• CompatibleContainerRuntimeRequired
• ContainerEnvironmentRequired
• ContainerRuntimeCompatible
• OpenContainersRequired

[jamezp]

I've got a new suggestion of @RequiresTestcontainers to make it more generic and really what this is about.

[rhusar]

I've got a new suggestion of @RequiresTestcontainers to make it more generic and really what this is about.

I like the that, but in reality is checks for docker/podman runtime? :-) Wouldn't that make it a bit of a misnomer?

[jamezp]

It does, but that's an implementation detail. We only check if it exists because that's what Testcontainers requires. If for whatever reason they switched to something else, it wouldn't make much sense. The idea is we're saying "Something in this test requires Testcontainers".

[jasondlee]

It does, but that's an implementation detail. We only check if it exists because that's what Testcontainers requires. If for whatever reason they switched to something else, it wouldn't make much sense. The idea is we're saying "Something in this test requires Testcontainers".

That's why I like (d?) @ContainerRequired. It doesn't imply or require a specific containerization engine.

[jamezp]

I'd be a +1 for @ContainerRequired too if we don't like @RequiresTestcontainers. The term "container" is overloaded, but I don't have a better suggestion other than explicitly saying "Testcontainers".

I do also like @OpenContainersRequired given that is the initiative name https://opencontainers.org/

[rhusar]

@jamezp @jasondlee Do we have stronger feeling about this since November? I think my excitement is now distilled to "anything without a proprietary company name" is sufficient to me.

We also toyed with the idea that this might not even be required, right? @jamezp does that still make sense?

[jamezp]

I think we do need the annotation. There's not a good way to handle a scenario where something like a WildFly Arquillian ServerSetupTask requires a container, but the test doesn't use the specific container. By annotating the test itself we can fail or skip early. We could see unpredictable errors if both the test and the ServerSetupTask are not both annotated. The test itself would still run, but the SST would either be skipped or fail.

As for the name... ...I'm not sure. In some ways I like @OpenContainersRequire only because that is the name of the initiative that Testcontainers, Docker and podman are based on. That said, @ContainerRequired seems fine too. I've got no strong preference between those two. The latter is shorter though :)

[jasondlee]

I'm with @rhusar: anything without a company name. I think @ContainerRequired is nice and succinct with any baggage related to companies, initiatives, etc.

[jamezp]

That works for me. My only thought on adding "Open" or "Test" in front of that was "Container" is really overloaded.

[rhusar]

That works for me. My only thought on adding "Open" or "Test" in front of that was "Container" is really overloaded.

Yeah, that's why I like the 2nd suggestion from the list, @ContainerRuntimeRequired because it solves the overload question and I don't see any ambiguity left. :)

[jamezp]

Well, that still feels ambiguous to me personally as both container and runtime are overloaded IMO :) That could mean Kubernetes, or OpenShift, or Testcontainers, etc.

[jamezp]

Actually, maybe we're overthinking this. The package name has testcontainers in it. That should be enough so I'm switching my vote to ContainerRequired :)

[jasondlee]

Ha! You're probably right, and as luck would have it, I have a PR open: #43 :)