Hallo! * Matthew Kennedy wrote: > Case #2: I want to provide a JDK adapter for GCJ. This is essentially > a set of wrappers for gcj, gij and rmic which provide JDK-like > commands: javac, and rmic (rmic is the same). Other distributions > such as Mandrake, Redhat and (IIRC) Debian provide such wrappers.
debian has it. > So I'd like to get some input. I'd like us to NOT export the > CLASSPATH environment variable. For that matter, I think we should > NOT export JAVAC, JAVA_HOME and JDK_HOME. If scripts and other tools > need these environment variables to work, then we should have these > variables sourced from some place on disk (perhaps a java-config > command to do this). I support that, but for a different matter: debian has the requirement, that no env variables should be needed to start a programm. if we want to come to a set of common packaging tools, this is a 'must' from the debian side. Also, this will become a pain, when you have kaffe, gij and sablevm in you packaging. It will result in failures, as this abstraction level will not be satisfied by all this JVMs (even with wrappers). Something like JAVA_HOME is not working with gij and ant (ant expects some things (eg. javadoc) in java.home, which are simple not there in any not sun derived JVM). IMO, these comamnds should be available through java-config (named findjava in the proposed debian java policy) and also subject to a list of 'known working', whic has to be maintained at the place og the call. To give an example: |JAVA="$(findjava kaffe gij sun-jdk-1.4)" #no sablevm will output /usr/bin/kaffe if kaffe is installed, /usr/bin/gij-wrapper-3.3 if kaffe is not installed, and /usr/lib/j2sdk1.4/bin/java is both are not installed, but suns 1.4 JDK (one of them is installe due to packaging dependencies) > Is this really even necessary??? If I download the JDK and install it > into (say) /usr/local, I never have to set CLASSPATH to include the > Java API stuff and compiler interface (such as rt.jar and tools.jar) No, AFAIK, these two should not be included in the CLASSPATH. debians kaffe wrapper does include it's runtime environment, too. > And lastly, I'd like to make the point, that CLASSPATH should be > really left to the user to control. IMO, it should not even there be nessesary. I can't come up with any situation, where it wouldn't be easier to include some options in the applications wrapper script, which would include certain changes in the CLASPATH instead of having the user exporting CLASSPATH in the $HOME/.shell_profile, which will screw up the next java app. Pluss, such options could go into the $HOME/.apprc If ant need some classpath adjustments, the only ant needs them (and should make them possible), but I don't want it in eclipse or any other app. I don't want to deal with sideeffects of this in my bugreports. IMO packaging should be as specific and strict as possible, leaving well defined ways to affect the bahaviour of the package. But defined in a way, so that only one app is affected and not all. Jan -- [EMAIL PROTECTED] mailing list
