[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

The first initial prototype for the new testsuite and build of JBossWS 5 
is available at 
https://svn.jboss.org/repos/jbossws/stack/cxf/branches/arquillian
I have converted the cxf-specific testuite to use Arquillian and 
temporarly disabled the shared-testsuite (it will be re-enabled once it 
will be converted too).
A basic README file has been added to the root of the project with build 
instructions; here is the content anyway:

  Building and running the testsuite
------------------------------------
The build follows the usual Maven flow; a wilflyXYZ profile has to be 
specified to tell the project which target container to use for 
integration tests; if no wildflyXYZ profile is specified, the 
integration tests are skipped.

 > mvn -PwildflyXYZ integration-test

The -Dserver.home=/foo/bar option can be used to run the testsuite 
against a given local server instance; the server does not need to be 
already running, as the build will create various standalone server 
configurations and start multiple instances.

The 'fast' profile can also be used to run tests concurrently.

  Updating WS stack
-------------------
In some cases it might be needed to build the ws stack and install it on 
a specified server instance without running the integration testsuite; 
this is achieved as follows:

 > mvn -PwildflyXYZ -Dserver.home=/foo/bar package

If a server.home property is not provided, the build creates a zip 
archive with a vanilla WildFly server patched with the current WS stack:

 > mvn -PwildflyXYZ package

the zip file path is 
modules/dist/target/jbossws-cxf-dist-${project.version}-test-server.zip


  Cleaning up
-------------
The project is cleaned up as follows:

 > mvn -Pdist,testsuite clean




As you can see, it is way simpler then what we used to have in previous 
JBossWS versions. The idea is to completely discontinue the binary and 
source distributions and distribute a simple zip file of the svn/git 
project, which the user will simply build like we do as explained above.

One of the major differences with the past is that having a local and 
running WildFly server instance is not strictly required anymore, as the 
JBossWS build goes and fetch the WildFly distros, self-installs on them, 
start them and run the integration testsuites. Few different server 
configurations are actually started (3 at the moment, I've been grouping 
together all the server setup requirements that can live together: 
security domains, system properties, etc.)
The server configurations are obtained by copying the standalone.xml and 
patching it using gmaven plugin (Groovy), which seems quite simple and 
easy to maintain.

Any comment, let me know. There's still quite a lot to do, to cleanup a 
bunch of stuff that we don't use anymore in the build, convert the 
shared and spring testsuites and nail down some transient test failures 
that can be reproduced when using the -Pfast profile (likely Arquillian 
related issues).

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss