2:33 p.m.
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...
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/jboss...
<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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>