[jbossws-dev] JBossWS testsuite reorganization

Jim Ma ema at redhat.com
Wed Dec 17 04:54:01 EST 2014


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

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 ?

> Cheers
> Alessio
>
> On 16/12/14 09:30, Jim Ma wrote:
>> Can we make wildfly900 profile as the default configuration ? If 
>> there is no any profile or system property specified, with "mvn clean 
>> install" it downloads wildfly900 dist ,install jbossws-cxf and run 
>> all the tests ?
>>
>> On 12/12/2014 12:44 AM, Alessio Soldano wrote:
>>> The first initial prototype for the new testsuite and build of 
>>> JBossWS 5
>>> is available at
>>> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/arquillian
>>> I have converted the cxf-specific testuite to use Arquillian and
>>> temporarly disabled the shared-testsuite (it will be re-enabled once it
>>> will be converted too).
>>> A basic README file has been added to the root of the project with 
>>> build
>>> instructions; here is the content anyway:
>>>
>>>    Building and running the testsuite
>>> ------------------------------------
>>> The build follows the usual Maven flow; a wilflyXYZ profile has to be
>>> specified to tell the project which target container to use for
>>> integration tests; if no wildflyXYZ profile is specified, the
>>> integration tests are skipped.
>>>
>>>   > mvn -PwildflyXYZ integration-test
>>>
>>> The -Dserver.home=/foo/bar option can be used to run the testsuite
>>> against a given local server instance; the server does not need to be
>>> already running, as the build will create various standalone server
>>> configurations and start multiple instances.
>>>
>>> The 'fast' profile can also be used to run tests concurrently.
>>>
>>>    Updating WS stack
>>> -------------------
>>> In some cases it might be needed to build the ws stack and install 
>>> it on
>>> a specified server instance without running the integration testsuite;
>>> this is achieved as follows:
>>>
>>>   > mvn -PwildflyXYZ -Dserver.home=/foo/bar package
>>>
>>> If a server.home property is not provided, the build creates a zip
>>> archive with a vanilla WildFly server patched with the current WS 
>>> stack:
>>>
>>>   > mvn -PwildflyXYZ package
>>>
>>> the zip file path is
>>> modules/dist/target/jbossws-cxf-dist-${project.version}-test-server.zip
>>>
>>>
>>>    Cleaning up
>>> -------------
>>> The project is cleaned up as follows:
>>>
>>>   > mvn -Pdist,testsuite clean
>>>
>>>
>>>
>>>
>>> As you can see, it is way simpler then what we used to have in previous
>>> JBossWS versions. The idea is to completely discontinue the binary and
>>> source distributions and distribute a simple zip file of the svn/git
>>> project, which the user will simply build like we do as explained 
>>> above.
>>>
>>> One of the major differences with the past is that having a local and
>>> running WildFly server instance is not strictly required anymore, as 
>>> the
>>> JBossWS build goes and fetch the WildFly distros, self-installs on 
>>> them,
>>> start them and run the integration testsuites. Few different server
>>> configurations are actually started (3 at the moment, I've been 
>>> grouping
>>> together all the server setup requirements that can live together:
>>> security domains, system properties, etc.)
>>> The server configurations are obtained by copying the standalone.xml 
>>> and
>>> patching it using gmaven plugin (Groovy), which seems quite simple and
>>> easy to maintain.
>>>
>>> Any comment, let me know. There's still quite a lot to do, to cleanup a
>>> bunch of stuff that we don't use anymore in the build, convert the
>>> shared and spring testsuites and nail down some transient test failures
>>> that can be reproduced when using the -Pfast profile (likely Arquillian
>>> related issues).
>>>
>>> Cheers
>>> Alessio
>>>
>>
>
>



More information about the jbossws-dev mailing list