On 18/11/14 13:27, Rostislav Svoboda wrote:
> Five months after I started this thread, I finally come back to
it with
> the result of some additional Arquillian investigation I did at the end
> of last week and a plan for dealing with the reorganization:
>
> - we'll be using the wildfly-arquillian-container-managed integration
> - we'll have multiple standalone.xml server configurations for testing;
> I plan to provide a solution for avoiding maintaining many confs,
> basically deriving them from the current container one (either by
> running CLI commands or by applying XSL transformations). The multiple
+1 for CLI
-1 for XSL .. this is way to hell ... we burned ourselves with XSLT files for AS7
SmartFrog templates
OK
> configurations are required for any test that needs e.g. a custom https
> connector
> - we'll be using the 'class' Arquillian container mode for any test
> requiring a custom server configuration (each test is going to have its
> own server configuration); all remaining tests will use the default
> (suite) container mode
> - all @Deployment will have 'managed=true', except for very few and
> special cases
> - all @Deployment will initially have 'testable=false' and all @Test
> methods will also be @RunAsClient annotated; later we will see if we can
> re-write some of the tests meant to run in-container which are currently
> using custom mechanisms (ejb3 / servlet client deployments).
> - we'll have a convention requiring deployment names to be unique (IOW,
> no more deployments used by multiple tests); there're are currently few
> deployments used in more then a test, but that causes more problems then
> benefits (also consider we could now avoid writing the actually jar/war
> to the filesystem by default)
> - we'll probably have a mechanism in the build to automatically retrieve
> the specified version of WildFly, clone it, generate the various
> standalone.xml, update the ws stack on it and finally have the testsuite
> run. No more need for 2 builds (ant + maven) for deploying the stack
> first and testing it afterwards
> - we won't need the RemoteDeployer stuff anymore ;-)
Will you create some document on
https://docs.jboss.org/author/display/JBWS/ with
description of rules and changes for JBossWS CXF TS ?
Sure, the build is likely
going to be different, so we'll need new
documentation on how to build and test JBossWS.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss