[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

Hi Rostislav,
thanks for the feedback, responses inline:

On 18/12/14 14:33, Rostislav Svoboda wrote:
> 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+
We definitely need to force the use of 1.7+ through a new parent, thanks 
for the heads up.


>
> 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. ?
Yes, makes sense, I'll do this.


>
> 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
+1

>
> 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
There's already a jira for this, we'll be working on it after the 
arquillian branch is merged to trunk. Link: 
https://issues.jboss.org/browse/JBWS-3859

>
> 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
Need to check why that's actually created there; we do have a ant plugin 
used in all modules for showing the current profile and jboss.home 
afair, perhaps it comes from that. I'll verify.

>
> modules/dist/target/wildfly-8.1.0.Final/bin/standalone.sh is not executable
> ==> AI: make it and all .sh scripts executable ?
Well, this is what comes from the wildfly distribution zip, perhaps the 
files in there should already be marked as executable (assuming that's 
doable..?) ?


>
> 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 ?
Actually, I've been seeing those on current build too. I think I 
remember I checked and the warnings would be solved by upgrading Xerces 
(which is currently kind of blocked)

>
> 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 ?
Yep, we need a note there telling the user to set -Dexclude-udp-tests=true


>
>> 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 :)
Sure. The jbossws hudson machine wipes out the whole maven repo every 
week. We can make sure the release process includes an explicit call to 
the repository cleanup.

> 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.
Definitely to me. It's almost 2015... people should really be 
comfortable with Maven ;-)

>
> 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 ...
Maybe, we'll think about it :-)

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss