Re: Java wrappers and java-common

[Michael Koch <konqueror@gmx.de>]

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