Java Reference
In-Depth Information
properties);
}
public void stop(BundleContext context) {}
}
After you've added this activator class to the build, you must remember to declare it in
the
OSG
i metadata—otherwise, it will never be called. This is a common cause of
head-scratching for people new to
OSG
i, because the framework can't tell when you
accidentally forget a
Bundle-Activator
header. When you've added an activator, but
it's having no effect, always check your manifest to make sure it's been declared—it
saves a lot of hair!
Bundle-Activator: org.gjt.sp.jedit.Activator
Your activator code uses
OSG
i constants and interfaces, so you must add the core
OSG
i
API
to the compilation class path in the jEdit build.xml. Otherwise, your new code
won't compile:
<javac ... >
<classpath path="../../../lib/osgi.core.jar"/>
<!-- the rest of the classpath -->
This
API
is only required when compiling the source; it isn't necessary at execution
time unless the activator class is explicitly loaded. One more build, and you now have
a
JAR
file that can run as a classic Java application or an
OSG
i bundle! The following
snippet shows the final set of bnd instructions for the jEdit mega bundle:
-output: jedit.jar
-include: org/gjt/sp/jedit/jedit.manifest
Bundle-Name: jEdit
Bundle-SymbolicName: org.gjt.sp.jedit
Bundle-Version: 4.2
Private-Package: *
Bundle-Activator: org.gjt.sp.jedit.Activator
One last wrinkle: you have to tell jEdit where its installation directory is by using the
jedit.home
property. Normally, jEdit can detect the installation directory containing
its
JAR
file by peeking at the application class path, but this won't work when running
it as a bundle on
OSG
i because the
JAR
file is loaded via a different mechanism:
$
ant dist
$
cd ..
$
java -Djedit.home=jEdit -jar launcher.jar jEdit
With this last piece of configuration in place, you should see jEdit start and the main
window appear, as you saw earlier in figure 6.8. It should also still work as a classic Java
application.
