My vote goes to #1 as well for the short term.
There also is a third option, which requires some more work but
provides a very nice balance.
A great deal of the slowness of this complex matrix execution can be
addressed to the continuous startup and teardown of services like the
various databases and the datastores.
Considering that each of those services starts in less than a second,
the problem is not the single startup but literally the compound
effect of the complex matrix: if we started say MongoDB, and CouchDb,
and all others, and all containers at the beginning of the suite, we
could then run matrix tests in a very efficient way, I'd bet we could
keep the full matrix *and* the testsuite under a single minute. The
goal would be to reuse a single WildFly (or EAP) startup to test on
each database; i.e. we need to share the running containers across
modules, or merge the integration tests in a single module per
Not sure how far Maven will be a problem for this.
For the OGM needs to test on EAP, I just dicussed with Davide (same
office today), and since we'd be testing an old version of EAP
(6.1.0.Alpha1 being the latest in public Maven repositories), our idea
is that this is too old to be useful anyway. We'll set up a profile -
disabled by default - which downloads and tests latest EAP to be used
by the Jenkins instance running at Red Hat.
On 25 March 2014 09:25, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
This is a follow up on
We keep piling up new backends, new containers to test and new rules
checked at build time. A consequence is that it is becoming less and
less pleasant to work on OGM.
You can see that n version of Naked+WF+EAP+... multiplied by m backends
simply will make this project horrendously slow to contribute to.
I imagine n = 3 or 4 and m = 10 in a medium term.
I see two options that would keep us around for a while:
1. Make the container integration tests only run with a specific option
activated on the CI.
2. Move the container integration tests outside in a different repo
I do prefer 1.
hibernate-dev mailing list