Java Reference
In-Depth Information
Subsystem-Content: A1;version=[1,2), A2;version=[1,2)
Repository
ESA 1
A1
SUBSYSTEM.MF
1.0.0
A1
1.1.0
A2
1.0.0
Framework
A1
A2
1.0.0
1.1.0
Figure 4.3 This subsystem refers to two bundles, both of which are available in the repository, but one
of which is present in the ESA at a higher version. The higher-version bundle from the ESA is used at
runtime, but the other bundle is provisioned from a remote location found in the repository.
VERSION RANGES, UNDECLARED DEPENDENCIES, AND PROVISIONING
We're sure you'll agree that provisioning is, at its heart, a fairly simple process. Why do
so many people find it confusing? To start with, the example above is rather simpli-
fied! Provisioning an ESA that exactly specifies the symbolic names and versions of all
the bundles it needs is indeed easy. In the real world, ESA s don't express themselves
like this.
The most common reason that bundles can't be provisioned is because the bun-
dles in an ESA aren't normally specified with an exact version. In fact, the ability to
specify bundles with a version range is a key advantage of ESA metadata. If a range of
versions is acceptable, it isn't possible to look for a single bundle in a repository. In
this case, you could make the simplifying assumption that you want the highest avail-
able version of the bundle that fits within the version range, but what do you do about
the dependencies of an ESA that aren't directly declared? For example, what happens
when packages are imported by bundles inside the ESA ? Even the symbolic name of
the providing bundle won't be known!
Search WWH ::




Custom Search