On Fri, Jan 04, 2008 at 04:42:30PM +0100, Vincent Fourmond wrote: > > 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 ?
java-common in Ubuntu has another mechanism applied to it (but its unused currently). Perhaps its possible to merge stuff from that. Gentoo has a mechanism that is more similar to yours. Can you pleas compare it with yours. Perhaps its also possible to re-use stuff. Before we move stuff into Debian java-common it should be completely working for most cases. Otherwise stuff tends to get another nominal member. We have enough of them already. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
