Deprecate CLI utility methods in RabbitMQ module

[eddumelendez]

Those utility methods couple the implementation to the cli, which is only provided when using management image. Also, although very convinient methods, it will be hard to maintain for every command in the cli.

[Philzen]

I see your point, but this change seriously broke the DX for us. In 1.19.0, we could initialize and configure the complete container in one command on a static field. B/c of the required exception handling (and also the different return type), we now would need to generate a dedicated ApplicationContextInitializer method to execute the raw commands via execInContainer.

What about moving these convenience methods into a dedicated subclass, i.e. RabbitMQMgmtContainer?

[Philzen]

Those utility methods couple the implementation to the cli, which is only provided when using management image.

Interestingly enough that is the default image:

https://github.com/testcontainers/testcontainers-java/blob/dd1427ebd30bbaba7f32184f1376b7c21e725ab5/modules/rabbitmq/src/main/java/org/testcontainers/containers/RabbitMQContainer.java#L39C40-L39C40

Also, although very convinient methods, it will be hard to maintain for every command in the cli.

@eddumelendez does RabbitMQ have a history of often changing or breaking the CLI options?

[eddumelendez]

Hi, few notes:

1. Default images should not be used. That's the reason why those are deprecated
2. Testcontainers responsibility is about container initialization

[Philzen]

@eddumelendez i understand you points and that this was the proper action to reduce scope creep of testcontainers.

Do you think it would be OK to keep the current containerIsStarted hook and simply expose a single fluid utility method on RabbitMQContainer where one could add commands to the values array?

At the end of the day that's the biggest loss here and it would be superawesome to still have a way of configuring "onReady" commands while keeping object initialization down to a single command that doesn't require additional exception handling (as it's completely fine the way containerIsStarted currently logs them).

[eddumelendez]

Do you think it would be OK to keep the current containerIsStarted hook and simply expose a single fluid utility method on RabbitMQContainer where one could add commands to the values array?

I think vault and consul are doing it like that. Indeed, this is something we have been discussing. But, aligning all the modules would be until version 2.0.

[oneiros-de]

May I kindly ask you to eat your own dog food and adapt your own tests, e.g. RabbitMQContainerTest.shouldCreateRabbitMQContainerWithExchangeInVhost ?