Thanks. It looks like we both used the JUnit plug-in for inspiration
My plug-in is actually very similar to yours
If you are willing to go the OSGi Manifest route with the native library path, it would be something like this in the Manifest.MF:
Bundle-NativeCode: /native/win32/jinput-dx8.dll; /native/win32/jinput-raw.dll; /native/win32/lwjgl.dll; /native/win32/OpenAL32.dll; osname=win32, /native/macosx/libjinput-osx.jnilib; /native/macosx/liblwjgl.jnilib; /native/macosx/openal.jnilib; osname=macosx, /native/linux/ ... (32-bit libs) ... ; osname=linux ;processor=x86 , /native/linux/ ... (64-bit libs) ... ; osname=linux ;processor=x86-64 , ... (solaris)
(Note: not tested
But it certainly works, actually I have done it with LWJGL two years ago (but it was just a private test then).
I really recommend doing it over modifying a system property at runtime (what if another bundle decides to modify the same property?). And removing unnecessary dependencies (e.g. org.eclipse.core.runtime) is really important for some users. There are definitely use cases for this plug-in outside of Eclipse (for example, an OSGi based game engine)
Also, on the same note (but this is way less important):
In Eclipse 3.4 (or maybe in 3.3 already) there is a new way for specifying source code location. Instead of adding a plugin.xml and declaring an extension, you could do it like this in the Manifest of the source bundle:
(and the sources should then be unzipped in the folders /lwjglsrc etc.)
i.e. if in the binary bundle, there is /x.jar, then the source bundle should have /xsrchttp://wiki.eclipse.org/PDEBuild/Individual_Source_Bundles
But this doesn't really matter as much as I don't see anyone wanting to use sources outside of the IDE.