> There are many problems - I've mentioned them before - like:
> * Smoke profile can either be default and need to be disabled
> explicitely for any other group; but in that case many people will
> forget to disable it which causes inference with other profiles.
> Or it would have to be defined explicitely - i.e. "no smoke tests run by
> default"
> * Huge unmaintainable pom.xml
> * Impossible to define multiple groups

These all sound livable for awhile to me.

AS 6 sounded livable for a while to some.

> * Hard to separate web/full or even make all tests run with full
> Etc etc. See the resources above, and the issues discussed on as7 list
> recently.

This works today in master. I just added multiple executions.

Okay, so it was ready for three days. I understand that coding is more fun than merging but what's the point of duplicating work and patching unsatisfactory harness?

> Compat tests are in different module anyway. This change is refactoring
> the integration module. The testsuite/pom.xml is affected too but only
> slightly - properties etc.
> Do/will the integration submodules need different classpath? BTW slight
> differences could be handled by tweaking deps in profiles.

Yeah so this is double maintenance, both of these have to be in sync right?

I don't understand - what's doubled here, opposite to having two pom.xml's? It's much less code this way.

> Regarding moving the test sources - is there anyone seeing any advantage
> in having them all in testsuite/integration/src/test/java ? It looked
> quite ellegant solution but if there's really no one liking it, let's
> move it :)

Seems like you skipped this paragraph, I recommend the last sentence to your attention. Following it will take us to "MORE SMALL MODULES".

Please keep in mind that
> some configs will need to be distributed across whole testsuite, and
> _every_ config "axis" (databases, IPv6, security,...) will need to be
> reflected in _every_ module. What's now few-lines pom.xml for each
> module may become a big ball of mud, pulling in things from parent
> pom.xml's.

Yeah i think referencing external files is a nice solution to this problem.

No. You can't externalize pom.xml's code to pass tons of properties to surefire and to Arquillian (which needs them duplicated right in pom.xml).

Regards,
Ondra