Mike said:
That seems pretty confusing. You put the manifest in the jar as Chris says
but there is no need for a "second jar" and there is no need for the
classpath, everything is referenced relative to the one jar. That is the
whole point in a double-clickable jar, you have one file to deploy to your
users and everything they need is there. If you have two files then things
can get out of sync. Why two jars Chris? Am I missing something?
There's no requirement to use the "Class-Path" manifest attribute or
additional JARs. If you don't want to use them, you can forget about
it.
But let's say I distribute my application with Jakarta Commons
HttpClient, and that in turn depends on Jakarta Commons Logging. I
*could* unzip those jars and package the classes with my own, but that's
far from ideal. Instead, I can place those JARs in the same directory
as my own, and then list them in the manifest "Class-Path" attribute.
That saves me from having to muck around with the Jakarta Commons
libraries' JAR contents and mix them with my own.
The advantages of an executable JAR are retained; this is separate from
the environment-variable or command-line classpaths, which are still
ignored. The paths of these jars are specified relative to the
executable JAR, *not* relative to the current working directory or
anything else that can change. So it's still position-independent and
environment-independent, but I chose to keep my code separated from
third-party code, so it's easier to drop-in replace the third-party code
later.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation