> > * Libraries must (?) have the name > > libXXXX[version]-java (where the version part is the necessary > > part of the version, like libxalan2-java, not libxalan2.0.0-java). > > There could be a libxalan2.3-java. It depends the software. In addition, > this means having libxalan1-java, libxalan2-java, etc.
I would argue this is what is meant by "necessary" (as opposed to "major", etc) - i.e. allow it to depend on the software. > Drop the '-' on the link target. Standard libraries do not have anything > like that. I agree with Robert; there's no particular need for a religious mirroring of C libraries. Sure, uniformity is nice but not to the point of getting in the way. As for this whole business of putting executable jars in /usr/bin, I'm not particularly keen on this idea. There are too many different JVMs with too many different behaviours. And what if I want to run one Java app under FooJVM and another Java app under BarJVM? I'd much prefer each Java app maintainer places a small startup script in /usr/bin that runs java directly. > > * Some sort of function should be there to get the classpath that > > a specific jar-file needs to run correctly. > > Use the META-INF/MANIFEST.MF(Classpath) attribute. IIRC, there was a thread on debian-java recently that discussed in great detail the drawbacks of this method. Again, what's wrong with a startup script in /usr/bin that sets $CLASSPATH to $CLASSPATH:/jars/that/i/need:/to/import ? Simple and pretty much guaranteed to work with any debian JVM. > /etc/java/default-classpath/jdk1.1 > > The above is a file that contains a list of jars that are part of jdk1.1's > system classpath. This is marked as a conffile, and owned by jdk1.1. Have you looked through the JVM registry proposals that I've posted to this list? I put up scripts on people.debian.org almost a month ago (with a post to this list) and nobody has signalled any problems. This would require each JVM to install a control file (similar to your proposal) with classpath information and more, and java-common would have a script that uses these control files to query a JVM or to find an appropriate JVM. > > There must be some mechanism to check which jvm that are > > currently running. And a easy way to select a good jvm. To > > me it seems that we should add a option to the java-wrapper > > to allow this, or? > > java --flavor Both of the above features are handled by the script mentioned above. Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] In twenty years we're gonna wake up in a tidal wave of crap. - Tori Amos, Yahoo Online Chat, April 13, 1998 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]