JAVA_HOME policy?
Recently, I've been building JBOSS/Tomcat packages for internal use and
eventual general release (I'll follow-up with another email for the
location of my working packages).
In doing so, I've had the need to build/back-port various other Java
packages to Debian stable. As I've done this, I've seen package after
package (mine included) depend on a JAVA_HOME environment variable set
somewhere, in some script. Most packages seem to use a config file or
init-script to define a local JAVA_HOME. Source packages often have
JAVA_HOME coded into debian/rules.
There are obviously a bunch of java packages out there simply based on
the different java homes I've seen hard-coded into each package.
I like the idea of JAVA_HOME in general. I don't like that it's
hard-coded into all these packages. It becomes a mess to upgrade my
JDK/JRE package...oh yeah, update /etc/default/*, grep through init
scripts, etc, etc. Every time I build a source package, I also need to
be sure I set the JAVA_HOME to match my system.
I'm wondering if there's a better way to handle JAVA_HOME.
Two options I can think of off the top of my head are...
1- a java-config program much like gnome-config or gtk-config.
this java-config would be maintained by the package developer
and could return things like JAVA_HOME and maybe other useful data.
java-configs could use the alternatives system as well so
/usr/bin/java-config always matches your /usr/bin/java and
/usr/bin/javac.
2- an /etc/default/java file with populated JAVA_HOME, again using
alternatives. Then source packages and other JAVA_HOME-needing
scripts can source it in order to get the correct JAVA_HOME.
Have there been discussions regarding this? What's the concensus on how
we should address JAVA_HOME? There must be a better way to handle it
than what we currently have.
-joe
--
Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
UNIX, Linux and Java Training
Reply to: