OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] Runtime-specific artifacts in conformance tests

Hi Mike,

I agree not mandating a build technology is a good thing. However, I think having a canonical build system is important for the following reasons:

1. It proves the test suite can be run and validates compliance

2. It provides an example of how the tests should be run. This is important for runtime implementors but also for independent compliance validation. For example, if a vendor creates their own build system, there is a canonical form which an independent party can use to determine if the tests were run in a valid way.

Regardless of whether there is a canonical build system, it is important the test suites themselves are viewed as vendor neutral. In my opinion, the test artifacts and any example build system should not depend on or reference libraries supplied by a specific runtime or vendor. There seems to be several areas where this comes up in the current test suite:

1. Referencing the Tuscany SCA jar. I think we agree the tests should not rely on this library. My solution isn't to make it publicly available in a Maven repository (although that would be a good thing) since doing so will probably require OASIS hosting their own repository, creating a project at an open source foundation that has a repository, or getting the Maven central repository to load it directly (which takes a long time). As an interim solution, my approach is to check the jar into the svn test case repo. On checkout, the jar will be included in the svn workspace. At build time, a Maven module will exists which calls an Ant script to install the SCA jar in the local Maven repository where it can be referenced by other build modules. If this seems like a good approach, I can provide an example of how to do this. As a longer term solution, having OASIS host their own Maven repository that is periodically synced to the central Maven repo would benefit not only SCA but other TCs as well. In order to enable this, the only thing that is needed is a web server and DAV access to publish Maven artifacts to it. I believe syncing with the Maven central repo would need to be coordinated with the Maven authorities and use a tool such as rsync.

2. Miscellaneous files (e.g. openjpa, commons logging, log4j) that are not required by the test suite. I think we agree these should be removed.

3. Use of Tuscany Maven plugins. I'm not sure what the Maven plugins do or why they are needed (I may be overlooking something but I can't find documentation for them). If you can tell me what they are intended for, we can can work on alternatives.

3. RuntimeBridge implementations. Again, in the interest of having the test suite appear as vendor-neutral as possible, my recommendation is not to include runtime-specific examples. Instead, these can be provided outside OASIS. For some vendors, providing a RuntimeBridge implementation that can be compiled may not be feasible due to licensing restrictions. For example, the RuntimeBridge may reference API classes that are distributed under a commercial license.  This would mean they are placed at a disadvantage as their implementation is not included. There is also a slightly different problem which is some RuntimeBridge implementations may reference libraries distributed under a license that is incompatible with a particular SCA implementation. For example, the Tuscany implementation pulls in Eclipse Equinox, licensed under EPL, which is incompatible with GPL software. The only option here for a GPL-based SCA runtime would be to modify the test suite to not include those dependencies. It would be cleaner if the test suite distribution where devoid of these dependencies in the first place. Just to reiterate, the main point I am making here aside from the licensing issues is the tests need to be as vendor neutral as possible. 

I appreciate your offer to assist with a Fabric3 client. If you can respond to the other specific emails related to the RuntimeBridge API, that will be helpful. However, I don't think the client binaries should be distributed as part of the test suite for the reasons mentioned above. Also, there is a practical consideration that it is easier for us to manage the Fabric3 test client if it is hosted in our own source repositories.



On Dec 14, 2009, at 9:09 AM, Mike Edwards wrote:


Thanks for taking this careful look at the OASIS Assembly test artifacts.

First, to comment on the various build artifacts.

The build artifacts are only provided as an example and are not strictly part of the testcase suite.
They are provided as a convenience and as a guide to how the test suite can be built.  No-one is
obliged to use any of them.  We cannot presume that people using the test suite will be happy to
use Maven or indeed any other build system - but the materials that are there are Maven based
and do work.

The 3 plugins that you identify are publicly available Maven plugins that assist in some common
tasks relating to building with Maven.  Again, no-one is obliged to use them.

The Tuscany SCA API JAR is as you rightly observe a necessary evil at the moment.  Ideally, there
would be an OASIS version of the SCA API jar publicly available from a Maven repository.  I would
appreciate your assistance in making this a reality, in which case this Tuscany dependency would
go away.  (I suspect that the Tuscany file would go away as well - the Tuscany project has no
interest in maintaining this file).

Regarding the dependencies of the Test_Client module, what you are seeing are the dependencies
of the test client as built as a client to the Tuscany runtime (I noted that the build artifacts are examples
and the client example assumes that it is a Tuscany client).

I am happy to work with you on creating a binary package that can be a client to the Fabric3 runtime.
I have not separated out the client into a "Tuscany client binary", "Fabric3 client binary" etc since
until this point no-one had come forward with anything other than a Tuscany client.  It will be good to
have a second client and a second SCA runtime and I am happy to work with you to make this a reality.

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From: Jim Marino <jim.marino@gmail.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 13/12/2009 15:01
Subject: [sca-assembly] Runtime-specific artifacts in conformance tests

In looking at the conformance assembly tests, I noticed a number of  
runtime-specific artifacts required for the build. Given these are  
supposed to be vendor-neutral, they probably should be removed before  
the tests are finalized:

- Tuscany SCA API jar
- Tuscany Maven Zip plugin
- Tuscany Maven Bundle Plugin
- Tuscany Maven Eclipse Plugin
- Tuscany runtime and Eclipse runtime libraries transitively pulled in  
by the Test_Client module. Running the Maven dependency plugin shows:

                [INFO] +- org.apache.tuscany.sca:tuscany-sca-api:jar:2.0-
                [INFO] +- org.apache.tuscany.sca:tuscany-node-launcher-equinox:jar:
                [INFO] |  +- javax.servlet:servlet-api:jar:2.5:compile
                [INFO] |  +- org.eclipse:osgi:jar:3.5.0-v20090520:compile
                [INFO] |  \- commons-cli:commons-cli:jar:1.2:compile
                [INFO] +- org.apache.tuscany.sca:tuscany-node-api:jar:2.0-

I realize the Tuscany SCA API jar was included because the OASIS  
version is not available from a public Maven repository. However, this  
could be handled by including the OASIS jar in the subversion  
repository and creating a Maven project that invokes an Ant script to  
install the jar in the local Maven repository where it will be  
available to the build. If would helpful, I can provide this.

I am unclear as to why the other plugins and runtime-specific  
artifacts are needed to build the test artifacts. I'm happy to help  
remove these once someone explains what they are intended for.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]