Re: Debconf Java BOF discussions
> I think we should mandate one of the standardised ways of doing dependency
> resolution so that in most cases application writers don't need to maintain
> recursive classpaths; java -jar should work and therefore jarwrapper can be
> used to avoid writing any wrapper at all (In fact, -jar doesn't work at all
> without a Class-Path attribute as -cp is ignored, so we can't make use of the
> Main-Class attribute either). It would also allow jh_depends to generate the
> correct dependencies.
>
is there a sane way of handling JNI? in particular directories in
addition to /usr/lib/jni , for picky libraries you don't want to modify
all too much.
packaging would be easier if we mandated that all JREs include
/usr/lib/jni by default in the search path for libraries. AFAIK this is
not the case now. or if we want to play nice with binary-only
proprietary JREs, a jh_install that symlinks in
/somestrangeJREdirectoryForJNI/. just an idea.
>
> - Currently the rest of 2.3 says that programs must have all the classes in
> /usr/share/java. Programs which aren't expecting their classes to be used
> as a library can surely ships jars in /usr/share/$program ?
>
if there is an advantage for programs, then why should they get special
treatment? surely any helper programs should be able to list
recursively? if upstream builds multiple jars then it might be best to
keep them separated. symlinking for versions would be done on the
directory in that case, not the contents.
given that openjdk probably becomes the most used JRE once 7 is out,
would it make sense to try and improve the manifest with version
numbering etc upstream? it might get java programmers to add this
information for us, reducing the amount of work on our end.
/Johan
--
--
------------------------------------------------
Johan Henriksson
MSc Engineering
PhD student, Karolinska Institutet
http://mahogny.areta.org http://www.endrov.net
Reply to: