Community
Participate
Working Groups
Build 20020416 Apparently it is possible to use absolute paths in the library attribute of plugin.xml. For example, <library name="jar:file:d:/commonutils/somjar.jar!/"/> Should we allow this? The documentation says library paths are *always* treated as relative to the plugin install location. This is inconsistent because we don't allow relative paths outside the plugin directory, such as: <library name="file:../somjar.jar!/"/>
I think we agree that using a path that references jar files outside the plugin install location is in general not a good thing, because it breaks the encapsulation. I personally wouldn't really need absolute nor relative pathnames for the jar files if it would be possible to setup more than plugin base directory using a path relative (possibly above) the Eclipse install directory. I will enter a bug report for this problem.
Hi, I jump into it after few discussion in the newsgroup with John. Sorry for my english used here :) I'm writing a plugin using some other application's jar. As We cannot know the location of this other app, i made a packaging with an installer (Installshield) who ask for the path of the other application and then wrote the plugin.xml file. I used the syntax described (<library name="file:c:/somefolder/somjar.jar!/"/>) in the plugin.xml file, and this approach is working good. So the problem is that i cannot include the Other Jars with my plugin, and i the only way for my plugin to work is to use this syntax. If you have any tips, they are welcome ! :) Cheers, Stephane
The intention to specify absolute paths can also be valid when packaging Eclipse for a Linux distribution. I don't want the Eclipse package to include jars already available via their native packages, and I'd prefer to have SWT installed separately to allow client apps running against it. The obvious workaround is making symlinks all over the place, but that's kind of ugly. Are absolute paths still allowed in Eclipse 3.0? What is the proper syntax for those?
*** This bug has been marked as a duplicate of 3074 ***
