[jbossws-dev] JBossWS testsuite reorganization

[Jim Ma]

On 12/17/2014 06:17 PM, Alessio Soldano wrote:
> 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.
But it's better than nothing. Besides that, we can always print a 
message and ask user to built it by himself if it's not available. At 
the moment , if we choose wildfly900 snapshot container, we have to 
build wildfly first, then we can start our jbossws test suite first.When 
we locally run the test suite, I need to either manually download a 
wildfly9 snapshot or update wildfly upsream and build it by myself, I'd 
expect this can be automatically handled in our build process.
> 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.
>
If there is wildfly900 snapshot is deployed, it is not that complex to 
run with wildfly900.
> As for our release criteria, btw, the testsuite is required to pass 
> against all supported target containers, which are all relevant.
I agree with this and no doubt. Choose profile to default not means, we 
don't need to make sure others are not supported.
>
>>> 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).
At the moment , wildfly900 build can be make sure not broken. Each PR 
will be checked before merge.
>>
>> 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
>
>