[jbossws-dev] JBossWS testsuite reorganization

Alessio Soldano asoldano at redhat.com
Wed Dec 17 07:02:12 EST 2014


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

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss



More information about the jbossws-dev mailing list