How to specify lib+path in JAR's Manifest?

Newbie & Debugging Questions
#1

For my App.jar which needs the Xith3d library, I include in the Jar’s Manifest the line:
Class-Path: xith.jar
It works fine on all platforms, in case the xith.jar stays next to the App.jar .

Also when I move the xith.jar to a (root) folder on the same drive it works. For example:
Class-Path: /Libs/xith.jar

But I can’t make it to work with Win32, when the lib is on another drive (on the same local computer). What I would like to have is something like this (which doesn’t work unfortunately) :
Class-Path: file://localhost/V:/Libs/xith.jar

Edit: With Linux it works easy of course, because it got a very developer and volume sharing friendly filesystem. For example:
Class-Path: /mnt/drive/Libs/xith.jar

Even under networked Win32 PCs you can do something like:
Class-Path: \\Server1\Store\Lib\xith.jar

(Of course you can also put both string in the class-path line with a space as divider, so it works on Unix and Win32.)

But how to make it work on a local Win32 PC ?

#2

You can use the network method on a local pc. Just share the folder containing the jar file (or a parent folder) and create the appropriate UNC path.
Personally I would just put all the jar files in places such that simple relative paths worked.

The Windows file system is every bit as real as that of Unix/Linux, unfortunately its file path syntax is often incompatible with various unix derived utilities. Particularly the presence of the ‘:’ causes problems for tools like make. Nor is Windows the only operating system that gives this kind of problem; VMS and MacOS have also frequently caused grief when porting unix applications.

#3

Off the top of my head under windows you can’t have both “localhost” and “V:” in one file URL. Again off the top of my head the reason is that Windows does not export “V:” as a network visible share (this is to do with windows security-through-obscurity. V is exported, but under the name V$, which causes it to be invisible).

Try:

file:///V:/libs…

(NB: I’ve got 3 slashes there at the start before the V:)

#4

[quote]You can use the network method on a local pc. Just share the folder containing the jar file (or a parent folder) and create the appropriate UNC path.
[/quote]
All the MS sharing and MS Netbios services don’t run on the PC, due to security issues. :expressionless:
But thanks for the hint, I’ll look what could be done…

[quote]The Windows file system is every bit as real as that of Unix/Linux
[/quote]
Personally I prefer a Linux/Unix filesystem any day over NTFS/FAT32; I am not saying NTFS is bad but it lacks a lot which makes developers and video fans happy (real links, real volume sharing, fast copying of large video files, and so on). But I’ve not intended to start a discussion about this; I just expressed my attitude that I can’t do several nice things under NTFS I could do with Linux/Unix FS… :expressionless:

#5

That’s it. It works. Thank you a lot.
I’ve still to say I don’t know why it works but anyway… :slight_smile:

So I’ll add this to the Manifest:
Class-Path: xith.jar file:///V:/libs/xith.jar
So the App.jar is happy when being run next to the xith.jar or “alone” on a different volume.

#6

Well, IIRC, then I explained it above. Basically, by ommitting the hostname, you cause it to use the local FS instead of a network FS. If you want to use the network FS then you need to specify a valid network mount point - and windows doesn’t export mount points with a colon in them, as explained above.

…but I could be wrong. It’s been a long time since I was administering windows servers.

#7

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. 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.

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.

#8

[quote]I think the other JARs should always be along side the main jar, OR in a place for standard extensions (jre/lib/ext),
[/quote]
It might be helpful to put executable jars in a directory and any (non executable) ‘library’ jars they need in a subdirectory.
It would be even better if the operating systems file browser presented a different icon for jars that were executable vs those that weren’t.

#9

[quote]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.
[/quote]
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:///v:/Libs/xith.jar /mnt/v/Libs/xith.jar

[quote]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.
[/quote]
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. :expressionless: (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, …

[quote]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.
[/quote]
Well, but they don’t have to worry because the additionally lib path won’t do any harm?