Re: Java wrappers and java-common

[Vincent Fourmond <fourmond@debian.org>]

  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 ?