On 6 May 2008, at 15:04, Thomas Watson wrote:
Glyn Normington <[EMAIL PROTECTED]> wrote on 05/06/2008
08:04:28
AM:
The Platform rewrites the manifests of the bundles of an application
(i.e. a PAR file) to use mandatory matching attributes to form a
scope. For example the following bundle of an application called
"MyApp" version 1.0:
Manifest-Version: 1.0
Bundle-Name: MyBundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: MyBundle
Export-Package: my.package.p
Bundle-Version: 1
is scoped to:
Manifest-Version: 1.0
Bundle-Name: MyBundle
Platform-Scope: MyApp-1
Bundle-ManifestVersion: 2
Bundle-SymbolicName: MyApp-1-MyBundle
Export-Package:
my.package.p;platform_scope="MyApp-1";mandatory:="platform_scope"
Bundle-Version: 1
Is Platform-Scope simply syntactic sugar for a matching attributes and
mandatory directives?
No. It's a record of the scope that was applied to the bundle so the
Platform doesn't have to reverse engineer the scope name from the
BSN, for instance. It enables the Platform to report the unscoped BSN
when necessary since that's the name that makes most sense to the user.
Does Import-Bundle allow for matching attributes
so you can get access to packages with mandatory directives? What
about Import-Library, how does this all map to the transitive bundles
included in a library?
Currently, import-library and import-bundle do not support matching
attributes. In both cases, the header is mapped to a set of bundles
and a package import is created for each package export, complete
with mandatory matching attributes. (Before you ask, this means we
can't currently import a bundle, or a library containing a bundle,
which exports the same package more than once.)
import-library is converted into package imports during manifest
rewriting, so you get the clean semantics of import-package with none
of the semantic rough edges of require-bundle.
What happens when you use Import-Bundle on more than one bundle that
exports the same package? This would be the typical "split" package
case with Require-Bundle. I assume the first one listed wins since
the framework does not allow a bundle to import the same package more
than once with Import-Package.
The Platform detects this situation, issues a log message, and fails
to deploy the importing bundle (and the rest of the PAR if the bundle
belongs to a PAR).
What about if you use Import-Bundle on another bundle that uses
Require-Bundle with visibility:=reexport? Do you also import
all the packages exported by the Required Bundle?
No, that's currently a restriction. This would be a little tricky to
implement on top of Equinox as we'd have to second guess which bundle
would turn out to be the required bundle and we tried to avoid
writing our own resolver. ;-)
I am also interested in some implementation details on how you
do the manifest rewriting (perhaps this can be taken off line
but I will ask here to start). I assume you are using the Equinox
adaptor hooks to transform the bundle manifests on bundle
installation.
I am wandering what you do for cases where Import-Bundle refers to
a bundle that is not yet installed. Do you rewrite the manifest again
once the imported bundle is installed? I am asking because the
Equinox
AspectJ incubator project does similar things and they had to work
through some issues to make sure the updates happened reliably.
No - the rewriting occurs in a subsystem which sits on top of
Equinox. Essentially, the rewrite of a bundle's manifest, and any
corresponding provisioning of other bundles, complete before the
Platform installs the bundle into Equinox.
Glyn
