Moving toward bundles - OSGi in Action - page 224

public void removedBundle(Bundle bundle) {
String path = getBundlePath(bundle);
if (path != null) {
PluginJAR jar = jEdit.getPluginJAR(path);
if (jar != null) {
jEdit.removePluginJAR(jar, false);
}
}
}
};

C

Maps to PluginJAR
instance

EditBus.addToBus(new EBComponent() {
public void handleMessage(EBMessage message) {
EditBus.removeFromBus(this);
pluginTracker.open();
}
});
}

D

Starts bundle
tracker

public void stop(BundleContext ctx) {
pluginTracker.close();
pluginTracker = null;
}

E

Ignores bundles that
don't map to file

static String getBundlePath(Bundle bundle) {
String location = bundle.getLocation().trim();

File jar;
if (location.startsWith("file:")) {
jar = new File(location.substring(5));
} else {
jar = new File(location);
}

if (jar.isFile()) {
return jar.getAbsolutePath();
}

return null;
}
}
The code identifies jEdit plugins by looking for a file called actions.xml in the bundle
root B . Because the jEdit API only accepts path-based plugins, it ignores bundles whose
locations don't map to a file E . To remove a plugin bundle, it uses another jEdit
method to map the location back to the installed PluginJAR instance C . The last piece
of the puzzle is to start the bundle tracker only when jEdit is ready to accept new plug-
ins. If you look at the jEdit startup code, you may notice that one of the last things it
does in finishStartup() is send out the initial EditorStarted message on the EditBus
(jEdit's event-notification mechanism). The code registers a one-shot component that
listens for any message event, deregisters itself, and starts the bundle tracker D .