Moving toward bundles - OSGi in Action - page 221

Bundle-Name: jEdit
Bundle-SymbolicName: org.gjt.sp.jedit
Bundle-Version: 4.2

Export-Package:\
org.gjt.sp.jedit;version="4.2"

Private-Package:\
org.gjt.sp.jedit.proto.*

-versionpolicy: [${version;==;${@}},${version;+;${@}})

Bundle-Activator: org.gjt.sp.jedit.Activator
Update your three bnd files as shown, and rebuild. Or if you want a shortcut, use this:

$ cd ..

$ ant jEdit.patch dist
Congratulations—you've successfully separated jEdit into three JAR files that work with
or without OSG i! The following lines launch jEdit OSG i and jEdit classic, respectively:

$ java -Djedit.home=jEdit -jar launcher.jar jEdit

$ java -jar jEdit/jedit.jar
As we hope this example demonstrates, after you have an application working in OSG i,
it doesn't take much effort to start slicing it up into smaller, more modularized bun-
dles. But is this all you can do with jEdit on OSG i—keep slicing it into smaller and
smaller pieces?

6.2.3 Loosening things up

So far, we've focused on using the first two layers of OSG i: module and lifecycle.
There's another layer you haven't yet used in this chapter: service. The service layer is
different from the first two layers in that it can be hard to tell when or where you
should use it, especially when migrating an existing application to OSG i. Often, peo-
ple decide not to use services at all in new bundles, instead relying on sharing pack-
ages to find implementations. But as you saw in chapter 4, services make your
application more flexible and help reduce the coupling between bundles. The good
news is, you can decide to use services at any time; but how will you know when the
time is right?
There are many ways to share different implementations inside a Java application.
You can construct instances directly, call a factory method, or perhaps apply some
form of dependency injection. When you first move an application to OSG i, you'll
probably decide to use the same tried-and-tested approach you did before, except that
now some of the packages come from other bundles. As you saw in chapter 4, these
approaches have certain limitations compared to OSG i services. Services in OSG i are
extremely dynamic, support rich metadata, and promote loose coupling between the
consumer and provider.