Re: a question about creating the JAR file
Sven K=F6hler wrote:
There are at least two ways of doing this:
1) create hello.jar (for example with ant) and embed a manifest file,
which includes helper.jar in the classpath. The good thing is: inside
the manifest, you can use relative paths. Doring java -jar hello.jar,
these paths will be resolved (AFAIK, relative to hello.jar)
"AFAIK" transforms to "It is thus" when you read the docs.
It would not make any sense to use absolute paths in the manifest.
2) unpack helper.jar, and include (almost) all files of helper.jar in
hello.jar. Now it's not always possible to do that, especially if you
have multiple JAR files. Some paths are reserved. For example, if you
create a StAX XML Reader, the API search the classpaths for certain
failes. Each files may contain the names of classes that implement the
StAX API. Now when you merge multiple JAR files, you would have to merge
these files as well. (This is actually a bad example, as you only want
only one StAX implementation anyways, but it illustrates the problem)
It illustrates _a_ problem; I wouldn't call it _the_ problem.
The problem is that it's a stupid idea.
You destroy the purpose of JARs, you tangle up code from multiple sources=
into a single vehicle, you violate copyright and licensing terms, you make =
it
more difficult to update third-party JARs, and there's absolutely no need f=
or
it.
What about signed JARs?
Now method (2) has gained popularity. Probably, because "big fat JAR
plugins" for several IDEs exist (at least for Eclipse this is true).
That's a result of bundling third-party JAR contents inappropriately?
However, I think this method should be avoided for any big application.
Drop the word "big" and you have good advice.
--
Lew