Java Reference
In-Depth Information
Deployment packages are greedy
These two different packaging strategies can't be used simultaneously. The specifi-
cation only allows resources to belong to a single resource package. Using both ap-
proaches at the same time or changing your approach after the fact would move
ownership of the bundle resources to another deployment package and thus violate
the specification.
A deployment package is defined as a set of resources that must be managed as a
unit. The resources in a deployment package are assumed to be tightly coupled, such
as a bundle and its configuration data. As a consequence, a resource can belong to
only one deployment package; otherwise, for example, you could run into situations
where you had two different, conflicting configurations for the same bundle.
another for the third or other combinations. When you create an update that adds or
removes resources from a previous version, you don't even have to package the
resources inside the update; instead, you can use
fix packages
.
FIX PACKAGE
A deployment package that minimizes download time by
excluding resources that aren't required to upgrade or downgrade a deploy-
ment package. It can only be installed if a previous version of that deployment
package is already installed. A fix package contains only the changed and new
resources. A fix package (called the
source
) therefore must specify the range of
versions that the existing deployment package (called the
target
) must have
installed. You'll see this shortly when we walk through the example.
Let's assume that you want to be able to add new shapes to the application when they
become available. In this scenario, it makes sense to start with a core deployment
package and create fix packages, adding new shapes as they become available.
Now that you've figured out your packaging approach, how do you proceed? You
need to create a manifest for the target that contains the paint frame and shape
API
bundles; you'll use this to provision the paint program core. Then you need to create
the manifest of the fix package that you'll use to add the three shape bundles to the
core. When you have your manifests, you need to create two
JAR
files with the corre-
sponding manifests and your bundles, you can optionally sign them, and you're good
to go. Here's the manifest of the core deployment package:
Manifest-Version: 1.0
DeploymentPackage-SymbolicName: org.foo.paint
DeploymentPackage-Version: 1.0.0
Name: paint-4.0.jar
Bundle-SymbolicName: org.foo.paint
Bundle-Version: 4.0.0
Name: shape-4.0.jar
Bundle-SymbolicName: org.foo.shape
Bundle-Version: 4.0.0
