posted 21 years ago
Actually, there are lots of ways of doing this... and JARring the contents of the other JAR is not the best way of doing this...
One way is to point to the other JAR file with the -cp option when you run...
This is kinda klunky because you'll probably want to make some kind of script launch the program, and you can't just click and run the jar file directly, but have to run the script instead.
The better way is to include a line in your manifest that points to the JAR files needed by your JAR files through a relative path. The manifest file for your JAR file should contain the line :
Which means that your JAR file needs to find the kunststoff.jar file in the directory called 'lib' below the directory that your JAR file is in. This way you don't have to have a script file to run, and you can click and run the JAR file directly.
Some of the reasons you don't want to unJar another JAR file and JAR it into your own are because you have just tied your application forever to that version (AKA 'tightly coupled'). If INCORS releases a new version of kunststoff next week, users can just dump the new kunststoff.jar into the lib directory and (most probably) be off and running. Another reason is that packaging libraries with your JAR may pose a problem with the license of that library. Kunststoff uses the LGPL... if you include the classes inside your JAR file you'll have to be sure to include the LGPL yourself with the code, etc. If you bundle the self contained JAR with your application or point the user to INCORS to download it you don't have this problem.
Of course, you probably aren't concerned with all this right now, and probably aren't distributing your code to anyone. This is just to let you know that making one monolithic JAR file out of all the libraries you need isn't the best approach.
-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.