UPGRADING OR CHANGING YOUR LIBRARY
One of the most reliable, and most frequently overlooked, ways of obtaining your
favorite library as an OSG i bundle is to go to the development site for the library and
look. You may feel that this advice is rather useless, but most people are surprised by
how many library developers have adopted OSG i packaging in the last couple of years.
This is another clear sign of OSG i's increasing popularity throughout the Java commu-
nity. Given that mature libraries are often released irregularly, it can be easy to miss a
release that adds OSG i metadata to the library's packaging.
If you can find an officially released version of your library packaged as an OSG i bun-
dle, it's by far and away your best option. Not only do you have a reasonable level of sup-
port, but you can also expect some thought to have been put into the packaging.
Typically, the only downside that you encounter when moving to an official OSG i pack-
aged version of your library is that you may have to take a newer version. This sometimes
leads to API changes, but unless the library has changed beyond recognition, and would
require you to significantly rewrite your application, it's the right way to go.
If you're already using the latest and greatest version of your library and you know
there isn't an OSG i version you can use, then you should definitely raise a requirement
with the library developers. It's possible that they're already thinking of adding OSG i
packaging, and even if they aren't, they will be after you've asked for it. They may not
know how to provide OSG i metadata, and so providing a patch with your suggested
OSG i helpers can often speed things up. If you're using a library that's no longer
actively maintained, or there's no chance of getting an OSG i-packaged release, then
it's time to get a little more creative in your search.
Most libraries aren't created in a vacuum; there are few that are the only choice for
providing a given function. Some libraries are much more popular than their compe-
tition, but that doesn't mean that the competition isn't worth considering. You may
find that even though the library you want to use isn't available as an OSG i bundle,
one of its competitors is. If it's possible to switch to another, OSG i-aware, library imple-
mentation with relatively little effort, then this is definitely worth considering. A less-
invasive option is to take advantage of a number of repositories that repackage popu-
lar libraries as OSG i bundles.
LET SOMEONE ELSE DO THE WORK
The whole point of using software libraries is to reduce the amount of effort that you
have to expend when writing your code. In that spirit, we recommend not moving on
to more drastic bundling steps until you've exhausted the possibility that someone
else has done the work for you. Even if the developers of your library have not yet
offered an OSG i bundle distribution, or you absolutely need a particular version of the
library for your application, that doesn't mean that there isn't an OSG i bundle for you.
The SpringSource Enterprise Bundle Repository
As is apparent from its name, this bundle repository is operated by SpringSource.
The Enterprise Bundle Repository contains a large number of bundlized open source
projects. These have their metadata generated automatically through bytecode analy-
sis, then packaged in with the code. This means that the EBR is a good place to find