Joerg Wendland wrote:
Barry Hawkins, on 2004-11-17, 09:29, you wrote:
That's what I have been doing, I just don't know if that's how we want
the Eclipse 3 package to work. Is that what other Java applications
that need JAVA_HOME are doing? It seems a bit of a kludge, but that
could be my inexperience with Debian packaging showing..
What about having sort of /usr/bin/java-config that returns the path to JAVA_HOME of the currently used JDK? So maintainers (of eclipse, tomcat, jboss etc.) could simply add a line like
JAVA_HOME=`/usr/bin/java-config --home`
to their scripts and be done. Additionally there could be a tool, maybe
named update-java-config, that allows for easy switching between
installed JDKs and accounts for all update-alternatives and telling
java-config the correct location of JAVA_HOME. java-config could be easily extended to support using JDKs that are currently not marked as
being the default one (and using non-free ones with additional features
like rmid etc.). This could look like:
JAVA_HOME=`/usr/bin/java-config --flavor=jdk1.4-sun --home` JAVA=`/usr/bin/java-config --flavor=jdk1.4-sun --bin=java` RMID=`/usr/bin/java-config --flavor=jdk1.4-sun --bin=rmid`
$RMID &
$JAVA my.tool.to.be.Run
We already have such a tool for Gentoo, written in Python. This is what it can do currently:
Usage: java-config [ OPTIONS ]
Options:
<< -h arg1[,arg2,...] --help=arg1[,arg2,...] >>
List all command line options with --help , for command specific long help
messages use --help=command (ex. --help=javac)
<< -J --java >>
Print the location of the java executable
<< -c --javac >>
Print the location of the java byte compiler
<< -j --jar >>
Print the location of the jar executable
<< -O --jdk-home >>
Print the location of the current jdk home
<< -o --jre-home >>
Print the location of the current jre home
<< -f --show-active-vm >>
Show the active virtual machine
<< -v --java-version >>
Print the version information for the in-use jvm
<< -p arg1[,arg2,...] --classpath=arg1[,arg2,...] >>
Print entries in the enviroment or package classpath.
<< -g argument --get-env=argument >>
Print an environment variable from the currently selected VM
<< -e arg1[,arg2,...] --exec=arg1[,arg2,...] >>
Execute something that should be somewhere in the JAVA_HOME
<< -l --list-available-packages >>
List all available packages
<< -L --list-available-vms >>
List all available virtual machines
<< -P arg1[,arg2,...] --print=arg1[,arg2,...] >>
Print the environment information for a specified VM
<< -S argument --set-system-vm=argument >>
Set the VM for the entire system
<< -s argument --set-user-vm=argument >>
Set the VM for a user
<< -A arg1[,arg2,...] --set-system-classpath=arg1[,arg2,...] >>
Set the system classpath
<< -a arg1[,arg2,...] --set-user-classpath=arg1[,arg2,...] >>
Set the user classpath
<< -B arg1[,arg2,...] --add-system-classpath=arg1[,arg2,...] >>
Append to the system classpath
<< -b arg1[,arg2,...] --add-user-classpath=arg1[,arg2,...] >>
Append to the user classpath
<< -X --clean-system-classpath >>
Clean the classpath of all packages
<< -x --clean-user-classpath >>
Clean the user classpath of all packages
<< -n --nocolor >>
Turn off all colors.
<< -i arg1[,arg2,...] --library=arg1[,arg2,...] >>
Print entries in the package library.
I don't know there is a Debian policy stating that such tools must be written in Perl and/or Bash on Debian, but if not, I think we may be well-served to fix java-config into working similarly across Gentoo and Debian (perhaps also Fedora?), so that users don't need to learn a new java-config every time they encounter a new Linux distro.
After all, cross-platformity works for pkg-config, which solves a much more difficult problem.
I'd be willing to spend time porting java-config to Debian if you guys are interested.
-- Karl T
PS. Also, suggestion for changes/improvements to the current java-config is more than welcome:)
