(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 <[EMAIL PROTECTED]>, http://www.iki.fi/jle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
