[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

On 18/12/14 08:37, Jim Ma wrote:
> On 12/17/2014 08:02 PM, Alessio Soldano wrote:
>> On 17/12/14 11:17, Alessio Soldano wrote:
>>> On 17/12/14 10:54, Jim Ma wrote:
>>>> 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).
>> I've had a look and it's not easily doable, basically because there's 
>> no way in Maven (AFAIK) to have a profile enabled unless another one 
>> (in a set of 2 or 3) is already enabled. The only solution is to have 
>> the wildfly800,wildfly810,wildfly900 profiles be controlled by the 
>> value of a command line property (something like 
>> -DintegrationTarget=wildfly810). In the main pom.xml, we'd need an 
>> additional profile for the default scenario, to be enabled when the 
>> property is not provided. We'd have to duplicate the whole wildfly810 
>> profile in modules/testsuite/pom.xml too, which is quite a big one 
>> (additional dependencies, additional plugins, etc in it), making the 
>> pom even harder to read.
> Can we set the wildfly810 configuration/dependency setting and plugin 
> in main pom.xml and remove the wildfly810 profile ? Then if there is 
> nothing defined, the container our test suite runs against is 
> wildfly810 final ?
No, we can't because we don't want the container dependencies to be part 
of the dependency tree in every module, but only in the testsuite ones. 
Those dependencies are for tests only (the stack must not be compiled 
against container specific apis).

Cheers
Alessio

>> I'm starting thinking this creates more problems then it actually 
>> solves. An alternative approach could be to have a profile using a 
>> antrun plugin to check if there's one of the 
>> wildfly800,wildfly810,wildfly900 profiles enabled (e.g. by checking 
>> the jboss.version property that's set by those profiles) and make the 
>> build fail with a nice message explaining what to do (either use one 
>> of those profiles, or set a property for preventing the check). WDYT?
>  If we can only resolve this with ant run plugin , it is a bit heavy 
> for this. I agree to use our old approach to trigger the profile with 
> property or maven profile flag.
>>
>> Cheers
>> Alessio
>>
>


-- 
Alessio Soldano
Web Service Lead, JBoss