Re: [sca-assembly] ISSUE 24: textual sca:include not sufficient

[Jim Marino <jmarino@bea.com>]

On Nov 11, 2007, at 10:02 AM, Scott Vorthmann wrote:

>
> http://www.osoa.org/jira/browse/ASSEMBLY-24
>
> On Nov 7, 2007, at 6:54 AM, Blohm, Henning wrote:
>
>> TARGET:
>>
>> Assembly Specification, section "Using Composites through Inclusion"
>>
>> DESCRIPTION:
>>
>> SCA's include mechanism for SCDL artefacts is described as a  
>> textual inlining of the included composite's body into the  
>> including composite.
>>
>> That leads to a set of problems:
>>
>> a) XML name spaces are ignored
>>
>> An included composite may make use of namespace prefices that  
>> become meaningless (or change meaning) when considered within the  
>> including composite.
>>
>> b) artefact resolution moves to the includer
>>
>> On the one hand SCDL artefacts may be re-used across contributions  
>> (see SCA deployment) and SCA's domain concept relies on inclusion  
>> to implement a cross-contribution assembly mechanism, on the other  
>> hand many SCDL declarations refer to artefacts that may not be  
>> resolvable within the includer's resolution scope.
>>
>> For example, implementation type declarations such as  
>> <implementation.java/>, <implementation.bpel/>,  
>> <implementation.spring/> refer to artefacts such as Java classes,  
>> bpel process descriptions, and application context XML files, that  
>> may not resolvable across contributions and much less on the domain.
>>
>> PROPOSAL:
>>
>> Describe sca:include over the assembly model of SCA rather than a  
>> textual operation - similarly to how <implementation.composite/>  
>> is described today.
>>
>> For example (simplified and using terminology that requires more  
>> explanation)
>>
>> All services, references, properties, and component elements of  
>> the included composite lead to services, references, properties,  
>> and component elements by the same name (resp.) in the including  
>> composite. Any other content of the included composite is ignored.  
>> Resulting component elements are opaque to the includer, that is,  
>> all artefact resolution required to evaluate the component  
>> declaration must be performed in the resolution scope of the  
>> included composite. This algorithm is recursively applied in a  
>> depth-first traversal.
>>
>>
>
"in the resolution scope of the included composite" does that apply  
to wires and autowire as well? I think the scope of the resolution  
should be the target composite, particularly at the domain level.

Jim