Folks,
I am very happy to discuss possible alternative structuring of the OASIS
testcases.
First, I hope I can motivate how they are structured right now.
Some comments inline...
Raymond Feng wrote:
There are a few pieces needed for a conformance test for Tuscany Java SCA.
1) The OASIS test framework, including the RuntimeBridge,
TestConfiguration, BaseJAXWSTestCase and TestInvocation WS.
2) The Tuscany implementation of RuntimeBridge
(client.TuscanyRuntimeBridge)
3) General resources such as the WSDL/XSD and composite files (under
src/main/resources/General)
4) General Java resources (under src/main/resources/General_Java)
5) Generate Java classes (under src/main/resources/General_Java)
6) Test-specific resources such as META-INF/sca-contribution.xml and the
composite files (under src/main/resources/<Test>)
7) Test-specific java classes (optional, under src/main/resources/<Test>)
8) A client test case for the specific test such as
client.ASM_4004_TestCase
I assume 1-5 is common to all Java related tests. My understanding is
that a typical test will involve:
a) 3 is packaged as the "General" contribution and 4-5 is packaged as
the "General-Java" contribution
b) 6-7 is packaged as the "Test" contribution
c) The Tuscany runtime will launch the test application using the SCA
contributions from b and c.
d) The client test case (8) uses 1,2 to launch the JAX-WS client to run
the test and verify the results
So from the code structure perspectives, it would be good see the
following projects in my IDE:
1) The test framework
2) The tuscany runtime bridge (depends on 1, or can be part of 1)
3) The General contribution
4) The General Java contribution (with SCAimports to 3)
5) The Test contribution (resources and java code)
6) The Test client for the given test (depends on 1).
The way the test suite is currently structured is that there is a Client piece and a series of SCA
Contributions.
The Client piece is 1) and 6), plus 2). 2) could in principle be separate, but what I have said in
the OASIS TC discussions is that it would be great to have every runtime bridge for all the
conforming runtimes available from OASIS and selected by a setting in the oasis-sca-tests.properties
file.
At the moment all the testcase clients are logically part of a single project. I don't see any
value in separating each client out into a different project. Effectively, each client is simply a
configuration which then uses the BaseJAXWSTestCase to execute the test, but they are packaged as
Java classes so that they are directly executable.
There is no Test contribution. The Test client is a JAX-WS program running direct on the JDK. So I
don't think that there is a 5).
The rest of the material is a series of SCA Contributions.
"General" contains material that is entirely independent of any language technology - Composites,
WSDLs and XSDs
"General_xxxx" like "General_Java" and "General_BPEL" contains base implementation material
including Composites, Java Classes, Java Interfaces. The name is meaningful - _Java means that the
contribution uses implementation.java and _BPEL means that it uses implementation.bpel. This is
extensible to any language, in principle.
Then there is a whole pile of contributions like "ASM_8001". They are separate because they contain
SCA material that in itself contains errors - eg Composites that are invalid because a reference is
not wired, for example. The reason that these must be separate is that in principle an SCA runtime
can reject such Contributions when they are contributed to the Domain - a runtime is eligible to
scan all artifacts and refuse to accept the contribution if it finds artifacts in error. So
artifacts containing such errors must be hived off into separate contributions to avoid them
contaminating the running of other testcases which do not use the artifacts that are in error. Note
that there are few specific language dependent Contributions too such as ASM_8001_Java.
I can see that each Contribution can become a separate Eclipse Project. Each
can be built separately.
At the moment, each Contribution is a directory. Composites and XML artifacts are straight in the
directory. Java is in subdirectories as dictated by their package names, such as
"org/oasisopen/sca/test". I'm happy to reconsider this organization if there is a better
arrangement that will suit Maven and Eclipse better, but the principle of keeping all of the
material of one Contribution in one Project/directory structure is an important one.
The output of a build of a Contribution is logically a ZIP containing the XML artifacts and the
compiled code artifacts. Those ZIPs must be available to the testcases - the actual location is
variable and can be set via a property string (see oasis-sca-tests.properties) The configuration of
each testcase names the Contributions it requires (and there is a setting for language available
that allows each testcase to be run using any of the available language implementations, which flips
the contributions which are language dependent.)
Ideas welcome...
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, July 29, 2009 10:09 AM
To: <[email protected]>
Subject: Re: running the otests
I think if Mike were open to reviewing the OASIS test structure we
should go further than this, The ant file in Tuscany doesn't
reorganize the code after it's checked out it's simply a tool to
generate poms that do the reorganization.It helps us trial what an
appropriate structure might be.
The main problem I found with trying to deal with the "all tests in a
single module" approach was getting it to work in Eclipse in a way
that was automatically generatable from the maven build. This becomes
particularly problematic if you want the contributions to be presented
as anything other than folders (something that is easy if the
contributions are in separate modules).
Regards
Simon
Yours, Mike.
