Re: [jbossws-dev] JBossWS testsuite reorganization

As Rosta suggested, the ARQ can help resolve some test issues. We also need to write some base or helper class to work better with ARQ to make all these things (configure the standalone.xml and change management model in runtime) much easier.

> > Proposals / idea > --------------------- > I'm listening to proposals to revisit the way the testsuite is run and > better address the point above. > Something I've been thinking about is relying on Arquillian, similarly > to what the WFLY testsuite does. What's not trivial is the fact that we > still need to have different version of the Arquillian SPI > implementation (that is, different WFLY / EAP versions) used depending > on a maven profile specified when running the testsuite; moreover we > also need to be able to run against the result of building the latest > WFLY master (iow, not a released target for which a > wildfly-arquillian-container-xyz is available on the repository). Adding profiles for different AS/WF versions looks the thing what we have to do. If WFLY master can publish all these snapshot artifacts during the teamcity build, we can consume it from the snapshot repo.

> We > could have custom server profile files (standalone-abc.xml) in the > jbossws sources for the supported containers to be used for starting > specific versions of the containers through Arquillian. The integration > tests could be split into groups meant to run against the various > different profiles of the selected target container. Pretty much > anything we need to customize on the server that can't be done using the > Deployer approach can actually be done through a proper profile file (I > would still keep the Deployer approach when working to limit the number > of profile files to maintain, as there's a lot of stuff in there). > Actually, we could even think about having a prepare phase before the > actual testsuite that runs given CLI scripts to obtain the desired > profile configuration. What about we creating more maven modules/directory for different server profile like WFLY's basic/domain/xts test maven module ?

> > Next steps > --------------- > Please provide feedback / ideas. Then we need a plan and eventually > jiras created. There could be many work to convert the test archive built with old ant script to new shrinkwrap. Is there any tool exists help us with this ?

We can consider to create some tool to allow us migrate to ARQ much easier and faster ?