9:10 a.m.
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...
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/jboss...
<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