OSGi组件依赖

    OSGi doesn’t allow you to specify class visibility at the class level, but instead at the level of the containing package.

1. The header：Export-Package and The directives for the Export-Package header

    当指定一个package export，默认的它的subpackage是没有exportde,需特别指定。

    Directives for the Export-Package header：

    (1)exclude : Specifies a list of packages that must be invisible to the component importing the

         package.
    (2)include : Specifies a list of packages that must be visible to the component importing the

         package.
    (3)mandatory： Specifies a list of mandatory properties that must be specified when using the

        exported package in other components.
    (4)uses : Specifies a list of packages that an exported package uses. This directive is used by 

        the dependency resolver to ensure that imported package versions correspond to those
        specified here.

    默认情况下，在Export Package是，OSGi框架会自动将ExportBundles的bundle-symbolic-name和Bundle

    -Version属性添加上。

    例如：Export-Package:
             org.springframework.beans.factory.serviceloader;
             uses:="org.springframework.util,
             org.springframework.beans. factory.config,
             org.springframework.beans.factory";
             version=2.5.5,
             org.springframework.beans.annotation;
             uses:="org.springframework.util,
             org.springframework.beans";
             version=2.5.5,

             ...

2. The header:Import-Package and It's stand attributes

    Standard attributes usable with the Import-Package header:

    (1)version : Specifies the version range for matching exported packages. If this attribute
        isn’t specified, the default value is [0.0.0, ∞).
    (2)bundle-symbolic-name : Specifies the symbolic name of the component that exports the

        packages. In the case of a fragment bundle, the name will correspond to the host bundle’s

        symbolic name instead. A fragment is a special bundle that allows extending an existing

        bundle.

    (3)bundle-version : Specifies the version of the component that exports the packages. As
        with version, the default value is [0.0.0, ∞) and the fragment behavior is as for bundle-

        symbolic-name.

    例如：

    Import-Package: javax.el;version="[2.1.0, 3.0.0)";resolution:=optional
    net.sf.cglib.proxy;version="[2.1.3, 2.2.0)";resolution:=optional,
    org.apache.commons.logging;version="[1.0.4, 2.0.0)",
    org.springframework.core;version="[2.5.6, 2.5.6]";resolution:=optional,
    org.springframework.core.annotation;version="[2.5.6, 2.5.6]";
    resolution:=optional

 

    In addition to the previous attribute, the resolution directive of the Import-Package header

    makes it possible to change the behavior of this resolution mechanism.The first possible value

    of the directive is mandatory, which is also the default.When a package is marked as

    mandatory, it means that if the package can’t be resolved, the component itself can’t be

    resolved. The other value is optional. In this case, if the package isn’t present during the

    resolution phase, the package isn’t considered imported by the component.

3. The header: DynamicImport-Package

    It bypass the regular class-resolution mechanism we have described and instead allows

    classes to be loaded on demand at runtime. Dependencies specified in this way are ignored

    during the transition between the installed and resolved states.

 

    The DynamicImport-Package header can contain a list of packages, but it also supports two 

    wildcards for specifying package names. Moreover, these imports are searched for in the order

    in which they are specified. This ordering is important, especially when using wildcards,

    because it determines the order in which matching occurs. In the following snippet, packages

    with the value test for the attribute myattribute will be preferred over other packages.

 

    DynamicImport-Package: *;myattribute=test, *

   
    No directives are defined for this header, but the standard version, bundlesymbolic-name,  

    and bundle-version attributes can all be used for package matching with the same semantics

    as Import-Package.

4. The header: Require-Bundle

    The Require-Bundle header is provided by the OSGi specification so you can consume all

    exported packages from other components based on component symbolic names.

    The Require-Bundle only has one attribute:bundle-version,the bundle-version attribute uses

    the same semantics as the version attribute of the Import-Package header and specifies
    the component version of the dependency.

    例如：

    Manifest-Version: 1.0
    (...)
    Import-Package: javax.servlet;version="2.5.0",
    javax.servlet.http;version="2.5.0",
    javax.servlet.jsp;version="2.0.0",
    (...)
    Require-Bundle: com.springsource.javax.servlet.jsp.jstl;
    bundle-version=1.1.2,com.springsource.org.apache.taglibs.standard;
    bundle-version=1.1.2

    注意：同一份MANIFEST.MF配置文件中，Import-Package header takes priority over the Require

    -Bundle header.

 

    Directives usable with the Require-Bundle header：

    (1)visibility : When set to private (the default value), the exported packages of the

    corresponding bundles aren’t re-exported. Setting this to reexport will achieve the opposite.
    (2)resolution : Controls dependency resolution. If set to mandatory (the default value), the
    dependency must be successfully resolved for the bundle to resolve. With the optional value,

    dependencies are only resolved if they’re present, and the bundle will resolve regardless.

5. Split packages

    You saw that referencing bundles with the Require-Bundle header is equivalent to importing

    all of their exported packages. A problematic case occurs when two different required bundles 

    export the same package. Such packages are named split packages because their content

    comes from several bundles.
    Although OSGi allows split packages, you’ll notice that they have several obvious drawbacks.
    When different bundles provide the same classes, unpredictable shadowing of classes can arise.

6. Matching and Versioning

6.1 Version Matching

    The different parts of a version value:

    (1)Major number : For major updates with no provision for compatibility with previous major     

         versions.
    (2)Minor number : For functional updates compatible with the current major version (compatible

        for clients using an interface, but not for implementers).
    (3)Micro number : For bug fixes.
    (4)Qualifier : Values like “–SNAPSHOT” for the current development version can also be added

        at the end of the value. The version number with a qualifier is lower than the number without.

6.2 Optional Depedencies

    OSGi supports optional dependencies on both packages and bundles with the Import-Package

    and Require-Bundle headers.

6.3 Attribute Matching

    模式：

    Header-Name: header-value1;directive-name1:=directive-value1;attribute-name1= attribute

    -value1;attribute-name2=attribute-value2,
    (...)

    例如：

    Export-Package: com.manning.osgi.simple;criteria="Manning";mandatory:="criteria"

    Import-Package: com.manning.osgi.simple;criteria="Manning"