Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How to specify lib+path in JAR's Manifest?  (Read 1507 times)
0 Members and 1 Guest are viewing this topic.
Offline Bombadil

Senior Member





« Posted 2004-02-24 07:37:45 »

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 ?
Offline Mark Thornton

Senior Member





« Reply #1 - Posted 2004-02-24 08:01:26 »

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-02-24 08:24:37 »

Quote

Class-Path: file://localhost/V:/Libs/xith.jar


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:)

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Bombadil

Senior Member





« Reply #3 - Posted 2004-02-24 08:38:46 »

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.

All the MS sharing and MS Netbios services don't run on the PC, due to security issues. :-|
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

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... :-|
Offline Bombadil

Senior Member





« Reply #4 - Posted 2004-02-24 08:43:36 »

Quote

file:///V:/libs...

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

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2004-02-24 09:13:52 »

Quote

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

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.


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.

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #6 - Posted 2004-02-24 11:16:33 »

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.

Offline Mark Thornton

Senior Member





« Reply #7 - Posted 2004-02-24 11:27:01 »

Quote
I think the other JARs should always be along side the main jar, OR in a place for standard extensions (jre/lib/ext),

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

Senior Member





« Reply #8 - Posted 2004-02-24 11:49:08 »

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.

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

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

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.

Well, but they don't have to worry because the additionally lib path won't do any harm?

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (40 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!