<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
Hi, <BR>
<BR>
1) Relevant resources:<BR>
<BR>
Tracking jira: <A HREF="https://issues.jboss.org/browse/AS7-2007">https://issues.jboss.org/browse/AS7-2007</A><BR>
Requirements: <A HREF="http://community.jboss.org/wiki/ASTestsuiteRequirements">http://community.jboss.org/wiki/ASTestsuiteRequirements</A><BR>
Docs: <A HREF="https://docs.jboss.org/author/display/AS71/Testsuite">https://docs.jboss.org/author/display/AS71/Testsuite</A><BR>
<BR>
<BR>
2) Modularization & moving the test sources<BR>
<BR>
<TT><FONT COLOR="#737373">> This is one thing I am wondering. If we all agree that many smaller modules is the way to go, since its the standard maven approach (supported by all existing maven tools), and it solves that various issues introduced by doing the grouping approach then maybe we should just do one refactor instead of doing this one and refactoring it yet again?</FONT></TT><BR>
<BR>
I'd like to see the problems with the solution in PR 710. Please send me instructions how to check that the IDE has problems coping with test sources on ../src/test/java.<BR>
(I don't know about Eclipse or IDEA, but NetBeans uses quite rational approach, which is simply running Maven for the active module. Which works.<BR>
It works for smoke, for -DallTests if you add that param, and also when running a single test. I haven't tried debugging yet but in worst case, I'd run with -Ddebug and attach the debugger.)<BR>
<BR>
<TT><FONT COLOR="#737373">> </FONT></TT><TT><FONT COLOR="#737373">I know you put a lot of effort into this, but there is a good chance this may net less work in the end since we wont be constantly tweaking this version. </FONT></TT><BR>
<BR>
It's not like switching from version A to B1 or B2, it's like staying at B (pull request 710) or going further to C (which would be moving sources to modules).<BR>
This harness is quite ready for both alternatives.<BR>
The reason I am proposing this as an intermediate state is, as I previously stated, merely technical: Moving thousands of files is a big operation from SCM PoV, so I want to get this tests relocation get merged as quickly as possible - i.e. move, test, make pull request, get it reviewed and merged, at best in a single day, otherwise I'll drown with new tests coming.<BR>
<BR>
> <TT><FONT COLOR="#737373">Or is there some set of requirements we have to meet ASAP that our existing testsuite infrastructure doesnt cover?</FONT></TT><BR>
<BR>
There are many problems - I've mentioned them before - like:<BR>
* 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.<BR>
Or it would have to be defined explicitely - i.e. "no smoke tests run by default"<BR>
* Huge unmaintainable pom.xml<BR>
* Impossible to define multiple groups<BR>
* Hard to separate web/full or even make all tests run with full<BR>
Etc etc. See the resources above, and the issues discussed on as7 list recently.<BR>
<BR>
> <TT>Although the problem stuart brought up is that we can't have different classpaths in a single testsrun.</TT><BR>
<TT>> </TT><TT>As an example compatibility tests would likley not be able to be ran in this way.</TT><BR>
<BR>
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.<BR>
Do/will the integration submodules need different classpath? BTW slight differences could be handled by tweaking deps in profiles.<BR>
<BR>
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 :)<BR>
<BR>
<BR>
3) Motivation driving the modularization<BR>
<BR>
In general, I'd like to:<BR>
<BR>
* Keep the number of modules at rational number - not fine-grained (difficult pom.xml maintainance), but not keeping it all-in-one at all costs (as it is now).<BR>
* Keep the pom.xml's easy to read and maintain - profiles interwoven like a fancy bread isn't exactly something I'd like to add features to.<BR>
* Keep the pure maven api concise and locical. 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.<BR>
<BR>
I think we can agree on these right?<BR>
<BR>
<BR>
Regads,<BR>
Ondra<BR>
<BR>
</BODY>
</HTML>