Java Reference
In-Depth Information
least vaguely well organized), it should be easy to identify its
API
packages. When these
packages have been identified, you should add them to an
Export-Package
header in
the manifest along with their version, which you may have to assume is the same as the
version of the library.
If the library you're packaging is simple or low-level, and only has dependencies on
core Java classes, then you're done at this point. Unfortunately, most libraries do have
dependencies on other library code. Some more complex libraries have large num-
bers of dependencies. Depending on the quality of the documentation for your
library, you may be able to find out what other libraries, and importantly what pack-
ages from those libraries, it depends on. Failing that, if you have access to the library
source you can read through it to find out what packages are needed.
After you've added in any necessary
Import-Package
header entries to your bun-
dle (complete with version ranges derived from the documentation or build depen-
dencies), you're ready to repackage your manifest into the
JAR
. This is a trivial
operation, but you should
not
use a standard zip tool to do it. The
JAR
specification
requires that the manifest file is the first entry in a
JAR
, something that you can't guar-
antee unless you use a tool specifically for creating
JAR
s. A good command-line tool to
use is the
jar
command, as follows:
jar ufm jarfile.jar ./META-INF/MANIFEST.MF
If you prefer a build tool to the command line, then there are a variety of other
options; for example, in an
ANT
build, as follows:
<jar destfile="jarfile.jar" manifest="META-INF/MANIFEST.MF"
update="true">
Signed JARs
In some cases, the library JAR you wish to convert may be signed, or perhaps the
license prevents you from modifying the JAR in any way, so that it isn't possible for
you to update the JAR manifest. Don't worry, all isn't lost! In this case, you should
create your OSGi manifest from scratch providing the same headers, but also adding
the header
Bundle-ClassPath: jarfile.jar
. What you need to do then is to cre-
ate a new JAR containing your OSGi manifest and also add the original library JAR to
the root of the new bundle. Simple!
Note that creating bundles in this way does have one major disadvantage. The bundle
can no longer be used as a normal JAR file because it has an internal classpath.
As you've seen, building manifests by hand is simple as long as the library
JAR
isn't
too complex. Sadly, as the library
JAR
becomes larger and has more dependencies,
that situation changes quickly. Identifying the dependencies for a library can be hard,
particularly if the library isn't well modularized (which is likely, given that it isn't an
OSG
i bundle). This makes hand-writing manifests of limited practical use in many
cases, which is why a number of tools have been developed to smooth the process.
