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.
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.
Search WWH ::