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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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


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




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