Hi Vincent,
comparing the wrapper script from FreeMind, version 0.9.0, not yet in
Debian [1], and your script, I'm missing the following features:
- no check that JAVA_CMD actually exists and is executable if the
variable is set.
- /usr/bin/java as last fallback if nothing else helps.
- debug output of java version found, and how the java command was found
(it helps a great lot when users ask for help and have e.g. a dangling
environment variable).
- a warning if the find_java_runtime is called with criteria and the
java command returned doesn't respect those criteria: i.e. JAVA_CMD is
set to gcj, and the script asks for 'sun'. I don't have a good solution
for this one, but it also helps avoiding bug reports where the user
forces the wrong Java command.
- the ability to ask for a maximum Sun version, as certain Java programs
don't work with newer versions. Perhaps create things like sunmin5 and
sunmax5 variables and be able to ask for those!?
- in my script, I also use JAVA_BINDIR to find the "right" java command.
It's a SuSE thing, but if we try to be truly cross-platform, we should
also consider it.
- I would define $DESTDIR/usr/share/java once as a variable and reuse it
throughout the functions.
- I also defined a variable ADD_JARS which is put in front of the CLASSPATH.
- the CLASSPATH variable is also used by the java command, do we have
here a consistent behavior across all binaries?
Cheers, Eric
[1]
http://freemind.cvs.sourceforge.net/freemind/freemind/freemind.sh?view=log&pathrev=fm_060405_integration
Vincent Fourmond wrote:
Hello,
Michael Koch wrote:
Before we move stuff into Debian java-common it should be completely
working for most cases.
I've looked at a fair amount of wrapper scripts, and the wrappers.sh
library I propose can be used to provide all their functionalities
easily save one, for bsh, where users can provide an additional
classpath with a -classpath option. (this can be done with wrapper.sh
but via an environment variable, though). There are a few wrapper
scripts (such as ant and others copied from it) which are quite complex,
and I'm not sure that they could benefit from wrappers.sh, but this is
just a couple.
That means that there would be no problem using this wrappers.sh for
most of the wrapper scripts in the wild. This way, we would win:
* adaptability: only one package to modify for new jvms (or new
properties)
* consistence: several possibilities of customization and debugging
shared across all scripts (and that really should help, especially for
bug reports...)
* and, for us maintainers, it should be painless to write wrapper scripts.
We would lose only in one point:
* all packages with a wrapper script would need a versioned Depends on
java-common. That shouldn't be much trouble, though.
The wrapper is LGPLed so it should not pose legal problems of any kind.
Do you mind me moving to the SVN of java-common, as I don't think it
is a good idea to go on in batik ? It wouldn't be installed if a new
version of java-common is necessary, it would only be present in the
source tarball. (but I understand if you don't like the idea).
I dont like that idea, but I can understand it. I think that would be
acceptable as long as the packages depending on java-common have the
right versioned depends.
I just committed the code into the java-common SVN[1]. This code *does
not get installed for now*. I'd like people to review and tell what they
think.
[1]: http://svn.debian.org/viewsvn/pkg-java/trunk/java-common/wrappers/
I'll let this thread stew for a while, and when everyone is happy (if
everyone is happy), I'll start thinking about uploading a new version of
java-common.
Cheers !
Vincent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
