Re: =?us-ascii:iso-8859-1:iso-8859-15:utf-8?q?Summary_of_the_id=E9as=2E?=
(I am fairly new to this list so please forgive me if I am suggesting
something that has been discussed earlier, just point me to archives)
On Fri, Nov 02, 2001 at 02:22:39PM +0100, Robert Bihlmeyer wrote:
> > Also, it may be beneficial for java-common to register
> > .jar/.war/.ear files with /proc/sys/fs/binfmt_misc, and provide a
> > wrapper script for running these. This could keep each binary
> > package from having to have its own wrapper script, in addition to
> > improving the usability of java in debian.
>
> Hmm, would the jars end up in /usr/bin, then? Or have symlinks? These
> would be better since you can have multiples point at the same jar.
> Should these "executables" be named foo or foo.jar?
Do jars include a magic that can be used to distinguish them from other
zip archives? If not then leaving out the extensions would make any zip
archive "executable" through binfmt_misc. I am not sure if this would be
a big problem.
> Another possibility is to just point the symlinks at the standard
> wrapper from java-common.
>
> In both cases it's unclear to me how the generic wrapper (invoked via
> symlink or binfmt_misc) would know which class to invoke. YACF?
In my opinion the directly executable jars should definitely include a
manifest file (META-INF/MANIFEST.MF) specifying the main class to be
executed. That is the standard way to create Java executables (and
consistent with other platforms).
If you need to have several entry points, you can always create separate
executable files without duplicating the code by doing the following:
- modify the manifest of the main jar to specify a new main class
- add the main jar to the class path specified in the manifest file
- create a new jar WITHOUT any classes, just the modified manifest file
Now you can execute the new jar which pulls in the classes from the main
jar (plus recursively any libraries needed by it) and executes the
alternative main class. I have used this for some Java software I have
deployed.
I think the manifest file would also be a natural place to define the
program specific class path additions so that the JVM can automatically
pull in the necessary libraries. That would make it also easier to
automatically determine the library dependencies as pointed out by a
previous mail. However, this would require that the library jars are
either referenced by a full path name or then the libraries and
executables should be located so that they can use relative paths to
refer to each other (something like "Class-Path: ../lib/xyzzy3.jar").
--
Johannes Lehtinen <johannes.lehtinen@iki.fi>, http://www.iki.fi/jle/
Reply to: