As you can see, one consequence of the repository allowing generic resources is that
the XML form is verbose!
Repositories are important, and we'll talk about them again later in this chapter.
First, now that you have a better understanding of how bundles are modeled, we
should take a deeper look at dependency provisioning, particularly how packages and
services can be located within a repository.
Now that you understand the generic descriptions of resources used by OSG i resolvers
and repositories, it's time to look back at how to provision bundles, and how you can
achieve finer control with your applications if you need to.
WARNING: BEST PRACTICES One or two of the examples in this section may
seem to deviate from the best practices outlined in chapter 5. As in all things,
context is king. The examples we provide aim to demonstrate best practices;
however, sometimes this doesn't offer the most elucidating examples. The
best practices from chapter 5 are good rules to follow, and we encourage you
to do so, but sometimes they aren't 100% appropriate. Perhaps in the future
you too will find that the right thing to do in your project is to ignore one or
more of the best practices. If it is, we wish you luck!
When we looked at provisioning applications, we primarily focused on how an applica-
tion manifest can require bundles within a range of versions. We also discussed the
concept of a missing dependency . You may have noticed, at the time, that we never dug
into how these missing dependencies were identified; more probably, you took for
granted that it would work.
Now that you know how bundles can be modeled and made available through repos-
itories, hopefully you can see how it might be possible to provision based on package
dependencies. What you can do is provide an example of a real-world resolution involv-
ing a repository. Your repository will contain three bundles (listing 7.2 and figure 7.7).
The bundles in your repository
Import-Package: fancyfoods.pkg; version="[1,2)"; foo=bar
Search WWH ::