Eclipse RCP/ Plug-in Question

Question

I have an RCP application (referred to as RCP-APP). I have created a new plug-in (referred to as plug-in A) that wraps a media player api (.jar file) and a folder of C libraries (dlls) that the media player api accesses via JNA. I then created another plugin (referred to as plug-in B) that contains a media player application that depends on Plug-in A.

When plug-in B is activated I get the following error messages informing me that Plug-in B cannot find the media player .dlls it is looking for:

!ENTRY org.eclipse.jface 4 2 2009-06-22 10:05:22.475
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.UnsatisfiedLinkError: Unable to load library 'libvlc': The specified module could not be found.

    at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:114)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:157)
    at com.sun.jna.Library$Handler.(Library.java:123)
    at com.sun.jna.Native.loadLibrary(Native.java:260)
    at com.sun.jna.Native.loadLibrary(Native.java:246)
    at org.videolan.jvlc.internal.LibVlc.(LibVlc.java:41)
    at org.videolan.jvlc.JVLC.(JVLC.java:45)
    at com.bah.gs.arts.jekyll.plugins.videolog.VideoLogDisplay.displayStream(VideoLogDisplay.java:32)
    at com.bah.gs.arts.jekyll.core.extensionpoints.DisplayStreamFactory.getDisplayStreams(DisplayStreamFactory.java:57)
    at com.bah.gs.arts.jekyll.core.views.medialist.MediaListView$1.doubleClick(MediaListView.java:91)
    at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:799)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.core.runtime.Platform.run(Platform.java:880)
    at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
    at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
    at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:797)
    at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1419)
    at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1173)
    at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:237)
    at org.eclipse.jface.util.OpenStrategy.access$0(OpenStrategy.java:234)
    at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:295)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3823)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3422)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2384)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2348)
    at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2200)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:495)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:490)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    at com.bah.gs.arts.jekyll.core.Application.start(Application.java:20)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

How do I inform Plug-in B (or the RCP-APP) that the .dlls are in a specific folder in Plug-in A?

It appears that the api expects to find the .dlls via it's environment PATH variable.

How can I essentially communicate "plug-in A/Folder-Name"?

Thanks for your assistance.

Answer 1

To get access to the .DLL files in plugin-a/folder you need access to the Bundle instance of plug-in A. One way is to implement an Activator for plug-in A which extends at least the class Plugin ("PluginA").

The call PluginA.getDefault().getBundle().getEntry("folder/some.dll") will return an URL to the .DLL file.

IMHO it is better to put all code that directly accesses the .DLL files into plug-in A. This way you don't need to expose the internal file structure of your plug-in to its users.

Answer 2

You will probably want to look at plugin fragments; this provides a mechanism to keep the public facing Java API apart from the (platform specific) dll/so files.

The packaging of SWT would be a good place to start looking at this sort of problem.

Answer 3

You could build a "binaries" plugin, put the dll in a subfolder bin/ of it, then make sure in the manifest * you add an activator + singleton property. * you check bin/ in the "Build", "Runtime Build" section

In the feature that includes your binaries plug-in, make sure to check "Unpack the plugin archive after installation"

In the activator of your binaries plugin, add something like this :

public enum Tool {reach, ctl, ltl};
private static URI toolUri [] = new URI [3];

public static URI getProgramURI(Tool tool) throws IOException {
    if (toolUri[tool.ordinal()] == null) {
        String relativePath = "bin/its-"+ tool.toString() ;
        URL toolff = getDefault().getBundle().getResource(relativePath);
        if (toolff == null) {
            log.severe("unable to find an executable [" + tool + "] in path " + relativePath);
            Enumeration<URL> e = getDefault().getBundle().findEntries("bin/", "*", true);
            log.fine("Lising URL available in bin/");
            while (e.hasMoreElements()) {
                log.finer(e.nextElement().toString());
            }
            throw new IOException("unable to find the tool binary");
        }
        URL tmpURL = FileLocator.toFileURL(toolff);

        // use of the multi-argument constructor for URI in order to escape appropriately illegal characters
        URI uri;
        try {
            uri = new URI(tmpURL.getProtocol(), tmpURL.getPath(), null);
        } catch (URISyntaxException e) {
            throw new IOException("Could not create a URI to access the binary tool :", e);
        }
        toolUri[tool.ordinal()] = uri;
        log.fine("Location of the binary : " + toolUri);

        File crocExec = new File(uri);
        if (!crocExec.setExecutable(true)) {
            log.severe("unable to make the command-line tool executable [" + toolUri + "]");
            throw new IOException("unable to make the command-line tool executable");
        }       

    }
    return toolUri[tool.ordinal()];
}

I copy pasted from some code of mine, so sorry it doesn't perfectly match your DLL example, I was getting executable paths from a restricted list (see enum Tool). The last step (setting the +x flag on the file) is probably useless in your case. On the other hand you get some exception handling code and a cache for free :) And its tested pretty thoroughly.

It does the job you are trying to do, pass the url to the binary to the downstream plugin.