Java Reference
In-Depth Information
WARNING: COMPLEX USES CONSTRAINTS
The examples in this section show
reasonably simple situations involving the
uses
directive, ones that are easy to
understand. You should, however, be aware that resolution problems involv-
ing
uses
constraints can be nasty to debug. This is because the class space of a
bundle includes not only the packages it imports, but any packages that are
used by those packages. In a complex case, you may find that the
uses
con-
straint violation occurs because of a third bundle, one that isn't even supply-
ing the package you're trying to import!
To minimize the risk of unpleasant
uses
problems, you should try to avoid
making use of too many
API
packages from other bundles when defining your
API
. In general, this isn't a huge problem; good
API
design tends to minimize
the dependencies on other packages, and even in cases with large
uses
clauses, problems are comparatively rare.
WRITING USES CLAUSES
You may have noticed that you haven't been adding
uses
clauses to your example bun-
dles. There are three main reasons for this. The first is that you don't want to overload
your samples with new concepts. The second is that because all your
API
comes from a
single, separate bundle, it must all be class-space consistent with itself, making you
unlikely to suffer from
uses
problems (another good reason for doing what we sug-
gest in section 5.2.1). The third reason is that writing accurate
uses
clauses is hard to
do and hard to keep up to date. In the real world, almost all
uses
clauses are gener-
ated by tooling, which you'll hear more about in chapter 8.
Package-based provisioning is extremely handy and is probably the most com-
monly used feature of an
OSG
i bundle repository. A well-structured repository, how-
ever, can offer more than packages for provisioning.
7.2.2
Service-based provisioning
Service-based provisioning works in exactly the same way as package-based provision-
ing, and it's easy to see why. If you look back at the resolution process, you can see that
despite the specific example, there was no reason that the requirements and capabili-
ties had to be packages at all. In terms of your restaurant example, if your
Test
bundle
had a requirement for toffee sauce (a requirement we can all get on board with!),
then it could have been satisfied by a sticky toffee pudding in your repository. Funda-
mentally, there's no difference between the two scenarios.
Having identified that service-based provisioning is a trivial extension of the pack-
age-based provisioning model, why does it warrant all of section 7.2? To answer that
question, you need to look back at the most critical part of the resolution and provi-
sioning process, the generation of the capabilities and requirements. For packages, all
the information you need is handily expressed in the bundle manifest, making pack-
age dependencies easy to model. Unfortunately, for services the problem isn't so sim-
ple, providing a key difference between services and packages.
