The example we've just looked at is a simple one, with a shallow level of dependencies; yet it already shows the value gained from the use of a proper dependency management tool. As bundles become richer in features, their dependency on other bundles, whether internal or third party, grows into a complex tree (sometimes a graph with potential cycles).
Keeping a close check on the dependencies of each project reduces the potential issues relating to the deployment of bundle upgrades. It will save you from lengthy searches for the missing dependencies— usually in the late hours of the night.
It is recommended to keep a checklist of those dependencies, the versions of each that have been tested and approved and the version that's currently being used. Also include their assigned OBR repository URL for quick access when using obr:repos add.
- What is an OBR?
a. It's OSGi's way of storing bundles
b. It's a service for querying repositories hosting OSGi bundles
c. It's a service that manages installed bundles
- What's the main difference between the
felix:installandobr:deploycommands?a. There's no difference
b. The main difference is that
obr:deployfinds and installs dependenciesc. The main difference is that
obr:deployuses the bundle presentation name - How do you install and start a bundle using OBR?
a. I use
obr:deploy; it will automatically start the bundle when it's installedb. I use
obr:deployto install the bundle, thenfelix:startto start itc. I use
obr:deploywith the-sflag to install and then start the bundle - How do you update an OBR repository?
a. I submit a request to the OSGi alliance; they will update it
b. I copy the bundle and then manually update the repository XML file
c. I use the bundle plugin in Maven to update the repository on bundle deploy