non-osgi jars: embedded in bundle or in plugin directory? [message #512165] |
Thu, 04 February 2010 09:33 |
Henno Vermeulen Messages: 126 Registered: July 2009 |
Senior Member |
|
|
We created a core system which makes use of 74 external jar libraries which we want to use in Eclipse RCP. It is not GUI specific.
We would like to start with the "one big bundle" approach of getting this core system to work, instead of having to OSGi-ify our core system and find OSGi bundles for our dependencies. (Later we should probably remove unneeded external dependencies and OSGI-ify our own system)
We can use Maven (with the bundle plugin) to create an OSGi bundle.
I already have successfully done this, but when I tell it to unpack all external jars before creating the bundle, the bundle jar will be in a big mess: resource files for different specific jars get into the root directory of the bundle and for example many LICENSE.TXT files are dropped because there can be only one such file.
The other option is to embed the jars inside the bundle (jars within a jar), which gives a very clean bundle jar. (Disadvantage: not usable outside of OSGi). This also seems to work, until the code in our own Eclipse plugin explicitly need access to a class from an embedded jar. Although this class is exported by the bundle and the jar is on the bundle classpath, the Eclipse compiler tells it can not find the class! Shouldn't this be supported by OSGi?
Am I doing something wrong here, or is this the usual behavior?
The last and probably currently best approach I can think of is to create a bundle which does not contain the jars but uses a "lib" directory for the external jars. Is this an official OSGi way? Or would this automatically mean we have to turn it into an Eclipse Plugin which can only be used by Eclipse? In this case, do we need to have a plugin.xml file?
[Updated on: Thu, 04 February 2010 09:36] Report message to a moderator
|
|
|
|
Re: non-osgi jars: embedded in bundle or in plugin directory? [message #512252 is a reply to message #512218] |
Thu, 04 February 2010 14:13 |
Henno Vermeulen Messages: 126 Registered: July 2009 |
Senior Member |
|
|
You are right, I can already do it using the PDE tools. I guess my question boils down to what would be the final structure when you export a bundle/plugin. I guess I could just use the export functionality and check this myself...
I would like to know this because there are a few disadvantages for us to your approach:
- I don't want to manually adjust the project each time our core system dependencies change
- other developers should be able to use the bundle and I really don't want to put the external libraries into source control so they can build it
- in the end I want to automate the build using a combination of Maven and Buckminster
To solve the first 2 points I would like to build a complete bundle/plugin with Maven which can be used in Eclipse from a network folder/p2 update site.
[Updated on: Thu, 04 February 2010 14:14] Report message to a moderator
|
|
|
|
Re: non-osgi jars: embedded in bundle or in plugin directory? [message #512908 is a reply to message #512267] |
Mon, 08 February 2010 10:38 |
Henno Vermeulen Messages: 126 Registered: July 2009 |
Senior Member |
|
|
This is annoying!!!!! When I see the FindBugs plugin they have external libraries under a lib directory outside of the bundle jar and have their Bundle-ClassPath set to lib/librarya.jar, lib/libraryb.jar, etc...
So I made a "plugin from existing jars" project where I manually move my libraries to a lib directory and prepend them with "lib/" in my Bundle-ClassPath. Surely this is the same setup as in the FindBugs plugin?
Before this move it worked fine, but now it says that it cannot find my Export-Package packages!!!!!!!!!
Edit: you have to remove all jars from the build path of the bundle, and add them in again so the build path now points to the jars in the new lib location. Then it works!
[Updated on: Mon, 08 February 2010 13:52] Report message to a moderator
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03750 seconds