system used by the Eclipse project where it manages updates that can be applied to
One of the key criticisms leveled at p2 is that it's perceived as being difficult to use.
This is probably because p2 is a more general provisioning solution, and so it's typi-
cally more effort to achieve specific use cases. Despite this drawback, p2 offers two par-
ticularly useful features that other provisioners don't.
If you have multiple dependencies that need to be provisioned, which you almost cer-
tainly do, then p2 can install them as a single logical unit within a transaction. If any
failures occur, then all the bundles will be uninstalled. This is different from other
provisioners, where a provisioning failure can leave you in an inconsistent state.
Over multiple provisioning operations, you may find that the same dependency is
needed by multiple bundles. In OSG i this is a good thing, because you gain the bene-
fits of runtime, as well as development time, reuse. Unfortunately, this can cause prob-
lems when you want to uninstall a particular bundle; you may know that no other
bundle is relying upon the bundle you want to remove, but what about the rest of its
dependency graph? After you remove one bundle, you may find that there are other
bundles that are no longer needed. This can be a long and difficult process, and may
remind you of Java's garbage collection model. With p2, these bundles can be garbage
collected automatically, saving effort for the runtime.
Apache ACE is a fundamentally different kind of provisioner than either Felix OBR or
p2. OBR and p2 operate on a pull model, where the client tries to find out what addi-
tional bundles it needs to get a particular bundle running. ACE , on the other hand,
operates with a push model. With ACE , you pick a set of bundles to install on remote
targets and then, as new remote targets become available, the ACE runtime will push
these resources out to the target. It should be noted that neither of these models is
truly pull or push , but it's a useful analogy.
Apache ACE doesn't provide the same resolution capabilities that you get with OBR
or p2, meaning that it doesn't fill many of the use cases we've discussed in this chapter.
ACE is, however, able to do something neither of the other provisioners we've dis-
cussed can: ACE can manage multiple OSG i application environments at once. This
facility is useful for enterprise OSG i where, as your scaling requirements grow, you'll
need to maintain more and more servers. Ideally, you would combine ACE with
another provisioning technology to get the best of both worlds.
Standard OSGi repositories
Several implementations of the OSG i Repository Specification are being developed at
the time of writing. JB oss is working on a well-supported implementation of the speci-
fication. Karaf Cave is a promising implementation, with support for both OSG i bundles