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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> 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 <sanne(a)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 <emmanuel(a)hibernate.org&gt; 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev