Hello, Michael Koch wrote: > "find_java_runtime" is harder. You actually need to run the programs to > really find out if a runtime works with a given program.
Well, this approach won't be practical. I preferred to use a system of 'capacities' : do we need swing, some of sun's classes, a java2 runtime ? I've written a tentative /usr/lib/java/wrappers.sh in batik (already uploaded). You can view it at http://svn.debian.org/wsvn/pkg-java/trunk/batik/debian/wrappers.sh?op=file&rev=0&sc=0 It is of course far from complete, as I lack experience with Debian java packaging. However, I hope it makes a good starting point. A typical script would look like: [ttf2svg]: #!/bin/sh # Include the wrappers utility script . /usr/lib/java/wrappers.sh find_java_runtime find_jars xercesImpl.jar batik-all.jar run_java org.apache.batik.apps.ttf2svg.Main "$@" [extract from rasterizer] #!/bin/sh # Include the wrappers utility script . /usr/lib/java/wrappers.sh # We need sun runtime. find_java_runtime sun || { echo "$0: Sun's java not found, some things won't work" >&2 find_java_runtime || echo "$0: No java found at all ! Aborting" >&2 && exit 1 } find_jars xercesImpl.jar batik-all.jar fop-transcoder.jar find_jars avalon-framework.jar commons-logging.jar commons-io.jar I'm thinking about moving wrappers.sh to java-common, so more packages could use this approach. Here are the advantages I see: * only one place to modify when features of the various jvm change; * a consistent interface for the user, with possibilities for debugging the processes of finding jars/java runtime. For instance: ~ DEBUG=1 ttf2svg [debug] /usr/bin/ttf2svg: Found JAVA_HOME = /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0 [debug] /usr/bin/ttf2svg: Found JAVACMD = /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java [debug] /usr/bin/ttf2svg: Runnning /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java -cp :/usr/share/java/xercesImpl.jar:/usr/share/java/batik-all.jar org.apache.batik.apps.ttf2svg.Main usage: java org.apache.batik.svggen.font.SVGFont <ttf-path> [-l <range-begin>] [-h <range-end>] [-autorange] [-ascii] [-id <id>] [-o <output-path>] [-testcard] * the writing of the scripts is much simpler, and the scripts more general/resistant; * some documentation could be shared in the form of a java_wrapper(7) manual page, explaining how the wrapper script work, the error messages and the possibilities for debugging. I don't see any drawbacks to this approach, as packages can transition to using that whenever they want, and that would only requires a versioned Depends on java-common. My questions to the team are: * do anyone object moving this wrappers.sh to java-common ? I believe this is where it belongs. * what 'capacities' could be interesting for find_java_runtime ? How could that be improved ? * any thoughts about other functions that would gain in being common ? A proper way to handle error/warning messages would be nice. * is there something I completely overlooked or missed ? Cheers, Vincent -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
