OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] [ISSUE 214] cyclic import resolutions in testcases ASM_13001, ASM_13002, ASM_13003, ASM_13004, ASM_13005, ASM_13006, ASM_13007, ASM_13008



On Jan 12, 2010, at 3:29 PM, Mike Edwards wrote:


Folks,

I believe that this issue is invalid.

The issue claims that "cyclic import resolutions" exist in the named testcases.
I believe that cyclic import resolutions are impossible by design for the SCA artifact resolution mechanism, as stated in Section 10.2.1 of the Assembly spec (CD04):


"When a contribution contains a reference to an artifact from a namespace that is declared in an import statement of the contribution, if the SCA artifact resolution mechanism is used to resolve the artifact, the SCA runtime MUST resolve artifacts in the following order:
1.        from the locations identified by the import statement(s) for the namespace. Locations MUST NOT be searched recursively in order to locate artifacts (i.e. only a one-level search is performed).
2.        from the contents of the contribution itself.
[ASM12023]"


I agree they are for namespace import/export *if* a contribution does not export the a namespace it imports or if exporting an imported namespace is defined as follows:

"if a contribution exports a namespace it imports, other contributions importing the namespace will resolve only to artifacts contained in the exporting contribution"

I actually think that would be a bad thing as it means artifacts would always resolve differently from within a contribution that exports a namespace it imports. Given this:

A<---import----(export)B<---import---(export)C

A would resolve an artifact contained in B while any references to the artifact in B would resolve to C. Note this is also different from how OSGi behaves for Java packages.

So, I think we need to define SCA import/export mechanisms more clearly and have that reflected in the test suite.


Note the normative statement here that forbids recursive searching of locations.

This means that if contribution A imports artifacts from a given namespace from contribution B,
and contribution B also imports artifacts in the same namespace from contribution C, then contribution A
DOES NOT import any artifacts in that namespace from contribution C (assuming A has no explicit imports
from contribution C).

This one-deep import mechanism precludes cycles.


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:  mike_edwards@uk.ibm.com





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









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]