Tools for building and testing - Enterprise OSGi in Action - page 191

With a few notable exceptions, most of the tools we'll discuss aren't specific to
enterprise OSG i. This is partly because you don't necessarily need enterprise tools—the
most important thing is support for core OSG i concepts like compile classpath and
launching an OSG i framework. A second reason we don't cover many enterprise OSG i
tools is that enterprise OSG i itself is new, and the tools are still catching up!
We won't specifically discuss IDE s—we'll get to them in chapter 9. But we can't
ignore IDE s, because for building OSG i bundles your choice of command-line tooling
and your choice of IDE are interconnected. Which command-line tooling you use will
influence which IDE works best for you, and the opposite is true as well; you may find
your choice of IDE makes the decision about your command-line build for you. In par-
ticular, you'll need to decide early on whether you want to use manifest-first tools or
code-first tools.

8.1 Manifest-first or code-first?

One of the great debates in the OSG i world is whether it's better to write manifests or
generate them automatically. Unlike a conventional JAR manifest, which is pretty bor-
ing, an OSG i manifest is absolutely critical to how an OSG i bundle works. Because
manifests are so pivotal, some people think they're much too important to be left to a
computer to write. Others argue that they're too important to be left in the hands of
software developers!
Writing the manifest for a complex bundle can be hard , and getting it right can be
even harder. For this reason, many developers prefer to write and compile their Java
code as though it were going to run in a normal Java environment. Tools can then use
this code to generate a manifest that's guaranteed to accurately reflect the code's
dependencies. This style of development is known as code-first. Some developers, on
the other hand, prefer to be more involved with the OSG i side of things. In particular,
they want to see and control what's going into their manifests.
Opponents of code-first development argue that although it's easy to automatically
produce an accurate list of packages a bundle should import, it's much harder to pro-
duce a list of packages the bundle should export. Generated manifests often export
more packages than you might have intended, particularly if you're using a service-
oriented style of OSG i. To keep your bundles as private as they should be, you may find
yourself having to pay as much attention to package exports as you would if you were
writing the manifest yourself.
Even the bundle imports might not turn out how you want them. Because the
packages you use are hidden with code-first development, you may end up using pack-
ages you would have avoided if you'd had to introduce an explicit dependency on
them. This can create bundles that fail to resolve at deploy time because of code
dependencies you don't even want or need. Manual tweaking is also required to
ensure that optional dependencies are flagged appropriately.
Manifest-first development, on the other hand, has its own difficulties. Develop-
ment can be slower because you may find yourself constantly interrupting coding to
go add required imports to your manifest. Although the tools should automatically