Hi, Mike.
Thanks for the clarifications. I think I'm mostly on the same page with you.
A few comments:
5) The Test contribution (resources and java code): I meant to say there
is an SCA contribution for the application code that is used by a test,
such as "ASM_8001".
There might be two possible ways to organize the contributions:
1) Each contribution will be in its own project and the structure follows
the Maven conventions. For example, we can have:
General:
src/test/resources
General_Java:
src/test/java
src/test/resources
ASM_4004:
src/test/java
src/test/resources
With this structure, we can easily build the modules using Maven and load
the projects into Eclipse. The Java and resource files are separated from
the source view and they be packaged together into the binary jar/zip.
2) All contributions are in one project. For example, we can have:
src/test/resources
General
General_Java
ASM_4004
The resources will be naturally partitioned by the names. The difficulty is
for the java files as the source view requires that folder structure matches
the package names. Unless we adopt a convention that different contributions
will use a different java package prefix, I don't see an easy way to
separate the .class files.
We can produce a test distribution using the Maven assembly plugin or ANT
scripts.
I'm leaning to Option 1. I think Option 1 is probably how SCA tooling will
lay out an SCA composite application in the IDE. We have been trying to set
up good practices in the travelsample application to promote a good scheme,
you can see the structure at:
https://svn.apache.org/repos/asf/tuscany/sandbox/travelsample
As the testsuite from OASIS, it would be great to demonstrate how SCA
contributions can be organized in the development and packaged for
deployment.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Friday, July 31, 2009 2:01 AM
To: <[email protected]>
Subject: Re: running the otests
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.
