Re: [sca-assembly] [ASSEMBLY-195] import and export of the same namespacefor some testcases - PROPOSAL

[Mike Edwards <mike_edwards@uk.ibm.com>]

Jim,

You're making interesting points, but
those points are about the Assembly spec rather than the testcases.

I believe that the testcases accurately
and correctly reflect the current spec and so I still take the view that

this issue should be Closed with No
Action.

You are welcome to raise a new issue
against the Assembly spec relating to the points you make.


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

From:	Jim Marino <jim.marino@gmail.com>
To:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	18/03/2010 16:38
Subject:	Re: [sca-assembly] [ASSEMBLY-195] import and export of the same namespace for some testcases - PROPOSAL

---

Comments inline.
On Mar 11, 2010, at 4:36 PM, Mike Edwards wrote:


Folks, 

I propose that ASSEMBLY-195 is Closed with No Action

ASSEMBLY 195 is concerned about testcase contributions which both import
and export the same namespace. 

The claim is made that this behaviour is not explicitly defined in the
Assembly specification and that it could 
lead to cyclic dependencies that would cause an error.

However, I think that the Assembly specification is very clear about the
meaning of import and export statements 
in Section 10.2.1 and there is a specific normative statement - ASM12023
- that indicates that any resolution of an 
artifact through an import statement must only be a one-deep search and
that searches do not recurse through 
multiple levels of Contributions. 

As a result, cyclic dependencies of the kind mentioned in this issue are
not possible. 

The claim that there needs to be a definition of an import/export pair
in the Assembly spec is also unnecessary, 
since its meaning is well defined by ASM12023, with no ambiguity.


To be precise, the claim is that the Assembly spec is
unclear about what the runtime should do in this situation, not that it
will lead to cyclic dependencies. After rereading the paragraph cited,
I still do not think ASM12023 is clear on the appropriate behavior. As
I mentioned in a previous post, consider the following:

Contribution A ---(resolve {urn:foo}bar) ---> Contribution
B ---(resolve {urn:foo}bar) ---> Contribution C
   ---(resolve {urn:foo}bar) ---> Contribution
C


Assuming contributions B and C both contain an artifact
X in {urn:foo:bar} and Contribution B imports and exports (resolve {urn:foo}bar),
the following may result:

1. References to X from artifacts in B will resolve to
the version of X contained in C
2. References to X from artifacts in A will resolve to
the version of X contained in B

Note that this behavior is different than OSGi and there
are directives in the former that can be used to avoid this from happening.


At a minimum, I think this needs to be clarified in the
assembly spec as users will invariably encounter this.  Import/export
of the same namespace is valuable in some situations but it needs specification.


Another way to look at this is: what normative statement
is import/export of the same namespace testing? 

Jim 




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

---

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