I strongly recommend not putting hard coded paths in your Jar manifest. I doubt very much that is the intention of the manifest entry for classpath.
The two hard coded paths aren't nice, that's true, but they will just be there additionally
. The "pure" lib name is always there at first. The manifest's line could look like this on a dual boot development PC:
Class-Path: xith.jar file:
I think the other JARs should always be along side the main jar, OR in a place for standard extensions (jre/lib/ext), though that will override any jars that are simply along side of your main jar, and so is less recommended.
At deployment time the lib jar(s) will of course stay next to the application jar(s) - plus optionally Webstarted.
However at development time I don't want to have the lib jars in any Java project needing it. Maybe you think: that's clear, so put it into the jre/ext folder. Well, I've done so and it worked nicely until recently, when the lib jars did try to load resource files which are relative to the calling application jar. It took me hours and hairs to find the problem. :-| (Btw. thanks Kev, thanks William)
Please have a look at this 3d model importing Xith thread
. In particular William's latest reply.
So in the end, to keep the lib stuff economically, at development time I've to store them at one central place. However I still want to be able to do the following for testing purposes (or let testing): start the application.jar file by double click, call the java app from within commandline, ...
The reason I don't think it is a good idea is that users are not likely ever going to look inside your jar - they will not know what path is being searched and this will likely lead to more confusion than it will be helpful.
Well, but they don't have to worry because the additionally lib path won't do any harm?