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
.
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
felix:install
and obr:deploy
commands?a. There's no difference
b. The main difference is that obr:deploy
finds and installs dependencies
c. The main difference is that obr:deploy
uses the bundle presentation name
a. I use obr:deploy
; it will automatically start the bundle when it's installed
b. I use obr:deploy
to install the bundle, then felix:start
to start it
c. I use obr:deploy
with the -s
flag to install and then start the bundle
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