On Sun Jul 12 21:37, Johan Henriksson wrote: > > 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.
Hmm, I think things really should be in /usr/lib/jni, particularly if: > 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. If it's not the case now then I think we should make the all include that by default (although jarwrapper, for example, makes sure it's on $LD_LIBRARY_PATH anyway). Playing nice with things outside main is always optional. > > - 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. Well, any jar which you expect someone to put on their classpath should be in /usr/share/java. Hence, libraries. If a library has a separate jar which should not be included directly, but picked up via a Class-Path: directive, that doesn't necessarily need to be in /usr/share/java, but it's a less common use case imo. > 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. Yes, once we decide on what we are doing, pushing it upstream is always useful. Matt -- Matthew Johnson
signature.asc
Description: Digital signature
