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.

Thanks,

Jim

 

 

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

Jim, 
 
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:   
 
 
  
 From: Jim Marino <> 

 To: OASIS Assembly <> 

 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:
 
                 org.oasis-open.sca.assembly:Test_Client:jar:1.0
                 [INFO] +- org.apache.tuscany.sca:tuscany-sca-api:jar:2.0- 
 SNAPSHOT:compile
                 [INFO] +- org.apache.tuscany.sca:tuscany-node-launcher-equinox:jar: 
 2.0-SNAPSHOT:compile
                 [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- 
 SNAPSHOT:compile
 
 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.
 
 Jim
 
 
 ---------------------------------------------------------------------
 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:
 https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
 
  
 

  

  
 
 
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