[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

On 17/12/14 10:54, Jim Ma wrote:
> On 12/16/2014 05:03 PM, Alessio Soldano wrote:
>> Hi Jim,
>> actually no, we can't, because when the latest moving target is used 
>> (wfly900 here, which comes from wfly master), the server.home prop is 
>> actually required, because the maven repo does not have the 
>> distribution artifacts.
> wildfly upstream is our jbossws project consumer, and we need to first 
> make sure everything works, like we already did in past. I know 
> wildfly upstream changes very quick even in each day, deploy the 
> snapshot artifacts will be time consuming work for their build 
> machine. But jbossws requires the latest wildfly dist snapshot and 
> make sure jbossws can work well with wildfly integration layer. To 
> resolve the wildfly dist snapshot is missing, we can look at download 
> it directly from our hudson machine. This would be helpful for our 
> user to try our code, we don't require them to pull whole wildfly 
> upstream and build all snapshot artifacts before running.
Making the build depend on the availability of a resource on jbossws 
hudson server is definitely a bad idea, sorry. That's a single machine 
which can be unpredictably down / not available.
We should not mix different goals / concerns here; if users want to try 
the jbossws code and implement something new, we're fine with them 
testing with any supported container. If they choose to play with the 
latest moving container (which is btw the hardest approach), to me it's 
perfectly reasonable to require them to pull it and build it.

As for our release criteria, btw, the testsuite is required to pass 
against all supported target containers, which are all relevant.

>> Generally speaking, I'm not sure we should single out a container and 
>> run the integration testsuite against that; if we actually decide to 
>> do this, a released target would need to be used (also for future 
>> build reproducibility, we don't want to default testing against a 
>> snapshot version)
> IMO, this is not a problem when both jbossws and wildfly are snapshots 
> and in development phrase. When we do release, we only need to release 
> the deploy stuff against wildfly9's future formal release or 
> wildfly810/wildfly800.
Anticipating a future release version is not a valid solution (you never 
know... and the build is broken till the release is actually available).
>
> What I want to propose is to simplify our build more. wildfly900 or 
> wildfly810 profile is required to run test suite, and we can take one 
> as the default setting. My goal is to use one simple "mvn clean 
> install" to build jbossws-cxf, deploy to wildfly and run the tests. If 
> wildfly900 is not a good option here, I am not against take wildfly810 
> profile as the default test container.   Your thoughts ?
I see your point. I can have a look at enabling by default the most 
recent released target container (wfly 810 currently).
Thanks for the feedback!

Cheers
Alessio


-- 
Alessio Soldano
Web Service Lead, JBoss