Re: [sca-j] [ISSUE 60] Sharing Java artifacts across contributions -updated proposal

Simon,

All 3 comments addressed in the latest
version of the proposal:

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31240/sca-javaci-1.1-spec-wd02_issue60g.pdf

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:  

From:
Simon Nash <>

To:
OASIS Java <>

Date:
13/02/2009 18:28

Subject:
Re: [sca-j] [ISSUE 60] Sharing Java
artifacts across contributions - updated proposal

Mike Edwards wrote:

> 

> Folks,

> 

> Here is the latest version.  Deals with uses directive on exports.

> 

> 

I have a few comments:

1. In the description of the "uses" directive, it says:

     The uses directive indicates that any SCA contribution that
imports

     this package MUST also import the same versions of any of
the

     packages contained in the uses directive.

    What does "same versions" mean?  The same
as what?  I can think

    of at least two possibilities.  Suppose contribution
X exports

    package foo at version 1.0 and package bar at version 2.0,
and

    the export for foo has a "uses" directive naming
bar.  In this

    case, "same version" might mean:

     a) When another contribution Y imports foo at version 1.0,
it

        must import bar at version 1.0.

     b) When another contribution Y imports foo at version 1.0,
it

        must import bar at version 2.0.

    Which of these is intended?  I think it should be the
second, but

    as currently worded it sounds more like the first.

2. In "Java artifact resolution" it says:

     If there is more than one contribution exporting the package,
then

     the contribution chosen is SCA Runtime dependent.

    In OSGi, it is guaranteed that the runtime will always load
the

    same version of the package.  I think we need to make
the same

    guarantee.  We don't need to say how the selection is
made, but

    I think the selection would need to be the same for every

    contribution that has an import for this package.

3. On the last call, we discussed improving the wording of the last

    paragraph in section 11.3.  The suggested text typed
into the

    chat room was:

     The thread context classloader of a component implementation

     class is set to the classloader of its containing contribution.

    This avoids the redundant statement that every Java component

    implementation is loaded by the classloader of the contribution

    containing the component.  This was already stated in
the first

    sentence of the first paragraph of this section.

The rest of the proposal looks good to me.

   Simon

> 

> 

> 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:  

> 

> 

> ------------------------------------------------------------------------

> 

> /

> /

> 

> /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/

> 

> 

> 

> 

> 

> 

> 

> ------------------------------------------------------------------------

> 

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  Follow this link to all your TCs in OASIS
at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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