+1 for option #1. Note that you already today can skip all integration tests by adding -DskipITs to your Maven command.
I think it'd make sense have a single module which houses all the integration tests which can then be executed against all possible container/datastore combinations. By default we could run just one combination, say ISPN on WildFly, while on CI all combinations are run via a Matrix job (with axes being container and datastore). Starting the servers beforehand would be a very nice improvement as well. --Gunnar 2014-03-27 13:07 GMT+01:00 Davide D'Alto <dav...@hibernate.org>: > > My vote goes to #1 as well for the short term. > > +1 > > > we need to share the running containers across > > modules, or merge the integration tests in a single module per > > container. > > Not sure how far Maven will be a problem for this > > I think it would be easier to start and download the containers without > using maven > and then run the maven build assuming that everything needed is already > downloaded and started. > > > > On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero <sa...@hibernate.org > >wrote: > > > 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 > > container. > > 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. > > > > Sanne > > > > > > On 25 March 2014 09:25, Emmanuel Bernard <emman...@hibernate.org> wrote: > > > This is a follow up on > > > > > > https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092 > > > > > > 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 > > > altogether. > > > > > > I do prefer 1. > > > > > > Emmanuel > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
