[jbossws-dev] JBossWS testsuite reorganization

[Jim Ma]

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 ?
> 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
>