[Fwd: test component implementation contribution substitution]

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

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.

Scott