Re: [sca-assembly-testing] [Fwd: test component implementation contributionsubstitution]

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Anish Karmarkar wrote:
> Forwarding on Scott's behalf.
> 
> -Anish
> -- 
> 
> -------- Original Message --------
> Subject: test component implementation contribution substitution
> Date: Wed, 26 Nov 2008 11:02:23 -0800
> From: Scott Vorthmann <scottv@tibco.com>
> To: Mike Edwards <mike_edwards@uk.ibm.com>,        Anish Karmarkar 
> <Anish.Karmarkar@oracle.com>
> 
> 
> (Whew.  That is a decidedly non-Anglo-Saxon subject line.  Dalmation
> plantation.)
> 
> Please forward to the right list... I'll join soon.
> 
> My idea for swapping out different implementation types in the context
> of a fixed set of test cases:
> 
> One or more generic contributions contain all the test composites,
> with wiring, promotions, bindings, etc.  Each of these contributions
> imports a fixed namespace, call it 
> "http://org.example/sca/implementationType
> ", prefix "IT".  The test composites exclusively contain components
> that use implementation.composite, and some of those implementations
> refer to a defined set of composite QNames in the "IT" namespace.
> 
> Each C&I TC is then responsible for creating their version of the "it"-
> exporting contribution, containing at least the set of composites with
> the expected set of names.  Each such composite will typically contain
> exactly one component, whose component type matches the properties and
> promoted services and references of the composite, and whose
> implementation is the technology in question.
> 
> The generic test contributions are therefore fixed, and don't need any
> changes to use different implementation types.  Swapping
> implementation types is effected by un-contributing one contribution
> exporting the "IT" namespace, and contributing another.
> 
> Vendors are also free to create their own versions of the "IT"
> contribution for any implementation types they define for their SCA
> runtime.
> 
> A slightly simplified version of this approach does not require
> separate contributions, but would let the test framework simply
> assemble partial contribution folder hierarchies having all the same
> characteristics mentioned above... the QName resolution would work the
> same, but the entire, self-contained contribution would be assembled
> by the ant scripts.  I have a preference for this approach, since it
> is less sensitive to the contribution population of the domain.
> 

On the last call, this (single contribution method) was what I was 
trying to outline. Mostly because it hadn't occurred to me that we could 
use our import/export mechanism. Which might be a better way. The only 
issue in doing this (multiple contributions) is that any implementation 
that wants to use our tests will require the ability to have multiple 
contributions and support the import/export mechanism. I don't remember 
if we have made this a requirement for conformance.

Dave: since you asked for more explanation on this (single contribution) 
approach --
This would be similar to multiple contribution approach in the sense 
that generic composites would contain the implementation.composites 
(along with wiring etc). The QNames for these implementation.composites 
would be fixed. Each C&I would "implement" the appropriate 
implementation.composites and keep then in a single directory. One can 
then just point the ant script to the particular C&I test directory and 
have it create a zip file for contributing. The zip file will contain 
everything that is needed. The ant script can be tweaked to point to 
specific directories for specific test, even allow mixing of C&Is.

-Anish
--