Community
Participate
Working Groups
I used the Bundle-ClassPath to reference external third-party libraries in my bundle with the Entry-Prefix "external:". If I give it the absolute path everything works fine, but if i replace it with there relative pathes equinox cant find the jars... I just tested with many differenzt relative pathes, but nothing worked! In the EclipseZone-Forums this problem was also described, but no solution or fix was given: http://www.eclipsezone.com/eclipse/forums/m91989699.html
When using relative paths what are they relative too? External paths used for the bundle classpath must be absolute paths. The external classpath does support variable substitutions so you can insert a variable into your path. For example: Bundle-ClassPath: external:$ExternalStuff$/somestuff.jar In this case the ExternalStuff must refer to an absolute path where the "somestuff.jar" is located on your system. In 3.2 we only supported variable substitution from system properties (e.g. ExternalStuff would have to be defined as a system property in the config.ini). In 3.3 we added support for environment variables but that will only work if you are using a 1.5 VM, 1.4.2 VMs throw exceptions when you call System.getenv. Say somestuff.jar is located in "/usr/mystuff/" then you should add the following property to your config.ini ExternalStuff=/usr/mystuff/
First: Thank you for the fast answer! I think logicaly, when I use the "external"-Tag, then the path is relative to my Startup-File, for example "eclipse.exe". Wouldn't it be a nicer to implement it that way, than to substitutions? Because than I don't must change the config.ini for every user I deliver to.
External classpaths should be used for resources that are completely external to the install base of eclipse (i.e. not under a sub-directory from where the eclipse.exe is located). If you can ship your resources under a sub-directory of eclipse then you should be able to package them directly in your bundle instead of making them external. If we used relative paths in the Bundle-ClassPath then you would have to change the Bundle-ClassPath in your bundle depending on where you installed eclipse relative to where your external resources are located. As a general best practice I would avoid external resources at all costs. We really think it is a bad idea to do it and we do not intend to propose this support back to the OSGi specification. External resources break modularity concepts because you cannot count on external versions to match your requirements. This leads back to the jar-hell problem which OSGi tries to solve with a proper modularity layer.
You are truly right in most of cases an i'm an fan of OSGi, too. But in real I must ship my software with many third-party libraries like database-drivers, frameworks etc. which I reluctantly edit and if it's only the Manifest file. Therefore it would be great if pathes with the "external"-tag would point naturally to the working directory of my application where the libraries are located in an subfolder. I think the word "external" implied that the following pathes are pointing to an "outside"-area of the jar and where should they better pointing at, than to the working directory?
(In reply to comment #4) > You are truly right in most of cases an i'm an fan of OSGi, too. > But in real I must ship my software with many third-party libraries like > database-drivers, frameworks etc. which I reluctantly edit and if it's only the > Manifest file. If you do not want to edit the third-party libraries then why not just include the jars directly in your bundle as-is and place them on your Bundle-ClassPath? The Bundle-ClassPath can include jars which you included inside your bundle. In this case the jar path *is* relative to your bundle's root, but you do not use the "external"-tag.
There are a lot of technologies out there within Eclipse so if you need to work with Database drivers for example, you should use DTP (www.eclipse.org/datatools) which makes it easier for you and is sort of standardized across the Eclipse ecosystem.
