Consider reverting split into individual module jars

[axelfontaine]

Not only is the current setup harder to maintain for you, but it is also hard for users to integrate. Just give us one single jar. Nice and simple. The modules are ultra-small anyway so a few K of overhead in the main jar are well worth it when one factors in the simplicity gains.

[bsideup]

Hi @axelfontaine,

Thanks for your feedback!

Actually, the reason for it wasn't the size. We did the repository split because of:

1. 3rd party modules
2. commercial integrations
3. overall CI time

Does it cause some issues to you? Or maybe you just want to see something like testcontainers-all with all the dependencies? (or maybe something like groovy-all, fat jar-like)

[axelfontaine]

Here is my pom.xml so far:

<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>postgresql</artifactId>
    <version>${version.testcontainers}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>mysql</artifactId>
    <version>${version.testcontainers}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>mariadb</artifactId>
    <version>1.3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>oracle-xe</artifactId>
    <version>1.2.1</version>
    <scope>test</scope>
</dependency>

What do we have here:

• a long list of dependencies which will only get longer as more specialized types of containers are added
• version numbers of individual modules that drift apart and in turn different versions of their transitive dependencies being resolved causing both high maintenance and potential conflicts

The fact that the version numbers started to drift is a clear indication that your current structure makes releasing too hard and ends up making life for end-users harder than it should be.

Alternatives:

1. Revert split and have a single jar from single project.
2. Use Maven modules instead of separate repos to make releasing easier, ensure consistent version numbers and compatibility between latest module and core versions. Optionally combine this with a Maven BOM.

Neither of these has an impact on the ability to create 3rd party or commercial modules. The same classes from core are still extendable and once can still create their own specialized containers. The only consequence would be potentially longer CI times which can most likely be largely alleviated with test parallelization.

[bsideup]

@axelfontaine,

We're in the middle of the split process, this is why some deps are not aligned with core.

But I get your point.

We were also thinking to crowdsource CI environment because CI times are critical for us ATM and Travis doesn't allow more than 5 executors per project for OSS. Windows / Mac OS X is another topic when we talk about CI :)

[asafm]

Apache Camel is a good example of mega project, which is why all plugins are aligned.
Dropwizard is a bad example as lots extensions have drifted making upgrading dropwizard very hard.
I favor Axel suggestion

[kiview]

I think Spring project as a similar problem, with lots of different modules and repos and they've solved it in Spring-Boot with the Spring-Boot-Parents and BOMs I think?

[kiview]

This is now further discussed in #564.