[jbossws-dev] JBossWS testsuite reorganization

[Rostislav Svoboda]

Some notes from my experiments with jbossws-arquillian-branch:

I tried to build everything with JDK 1.6, the only problem was with containers:
  jbossws-wildfly810 -- javac: invalid target release: 1.7
http://anonsvn.jboss.org/repos/jbossws/maven/parent/tags/jbossws-parent-1.1.0.GA/pom.xml says 
          <source>1.6</source>
          <target>1.6</target>
==> AI: new parent with 1.7 as source and target ?
==> AI: add info into README to use JDK 1.7+

mvn -Dmaven.test.failure.ignore=true -Pwildfly810 package requires org.jboss.ws:jbossws-wildfly800-server-integration:jar:5.0.0-SNAPSHOT 
      <dependency>
        <groupId>org.jboss.ws</groupId>
        <artifactId>jbossws-wildfly800-server-integration</artifactId>
        <scope>provided</scope>
      </dependency>
      <dependency>
        <groupId>org.jboss.ws</groupId>
        <artifactId>jbossws-wildfly810-server-integration</artifactId>
        <scope>provided</scope>
      </dependency>
==> AI: put these dependencies into separate profiles - wildfly810, wildfly800, etc. ?

http://anonsvn.jboss.org/repos/jbossws/container/wildfly81/branches/jbossws-wildfly810/pom.xml
    <wildfly.version>8.1.0.CR2</wildfly.version>
==> AI: update to GA

anonsvn.jboss.org/repos/jbossws/container/wildfly82   ... not available ...
==> AI: create wildfly82 container or add note (where ?) wildfly81 can be used with WildFly 8.2.0.Final

mvn -Dmaven.test.failure.ignore=true -Pwildfly810 package
among others produces:
  ROOT/target/antrun/build-main.xml ==> remove ?
  build-main.xml present in other modules too, afaik ant makes sense in dist module for WF preparation
==> AI: clean unnecessary ant related stuff

modules/dist/target/wildfly-8.1.0.Final/bin/standalone.sh is not executable
==> AI: make it and all .sh scripts executable ?

I see following warnings at the end of TS execution - mvn -Dmaven.test.failure.ignore=true -Pwildfly810 clean integration-test:
Warning:  org.apache.xerces.parsers.SAXParser: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.
Warning:  org.apache.xerces.parsers.SAXParser: Property 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized.
==> AI: cleanup, but how ... upgrade xerces ?

Following tests failed - mvn -Dmaven.test.failure.ignore=true -Pwildfly810 clean integration-test:
  testProbeAndResolve(org.jboss.test.ws.jaxws.samples.wsdd.WSDiscoveryTestCase): Number of matches can not be 0.
  testClientSide(org.jboss.test.ws.jaxws.cxf.udp.UDPEndpointAPITestCase): Could not send Message.
  testBroadcastUDP(org.jboss.wsf.stack.cxf.addons.transports.udp.UDPTransportTest): Could not send Message.
"Problem" is in firewall ...
==> AI:  README -- info about proper environment setup ?

> 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.

This must be ensured to work (with empty local maven repo) ... all the time :)
Makes kind of sense to drop maintenance of ant based installation procedures, this will push users to take a look at JBossWS code. 
There is possibility that this step will discourage some people. But I guess it's acceptable risk.

Maybe for latest JBossWS on latest WildFly we could provide zip directly - from modules/dist/target/jbossws-cxf-dist-5.0.0-SNAPSHOT-test-server.zip
It's already generated in jobs in http://jbossws-qa.jboss.org:8280/hudson/ ... so archiving the artifact shouldn't be a problem ...

Cheers.
Rostislav

----- Original Message -----
> 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
> 
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>