[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. Thanks, Jim On Dec 14, 2009, at 9:09 AM, Mike Edwards wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]