views:

11

answers:

1

Greetings, I have a java project which I export as a jar. This java project also uses JNI. So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin. I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment. However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time. That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)

This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.

If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.

Is there any method you can think of which may help me run this process smoothly?

Best Regards Seref

A: 

An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:

Bundle-Classpath: external:/path/to/your/lib.jar

During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.

(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)

pmf
If it works with JNI (which is a nightmare in terms of paths etc) this would be a good solution for development time. Since I do not have the book, may I ask if the bundle-classpath value can be used to refer to relative paths in eclipse? external:... requires an out of eclipse path to be configured..
It works with environment variables, so during development, you could define a environment variable pointing to your workspace (let's call it $EXTERNAL_DEPS) and use external:$EXTERNAL_DEPS/some_project/libs/lib.jar in the Bundle-Classpath. On the other hand, if you need to extract native libraries or deploy the bundle as a directory instead of as a JAR, I'm not sure how much you gain by my suggestion. I don't know if Bundle-NativeCode allows the external-stuff that is possible with Bundle-Classpath.
pmf