Java Reference
In-Depth Information
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.