Hm, seems that the only real difference is, that in your case the JVM
will pickup some jars because they ar ein a special dir and in my
case, it wll be picked up because -bootclasspath is used. One other
So far, this is the only options we use:
$JAVACMD $FLAGS -classpath $CLASSPATH $OPTIONS $MAIN_CLASS "$@"
I must admit to not understanding much about the connection between -bootclasspath, -classpath, and -extdirs even after reading the Sun documentation, but if it makes sense, then all three could be used.
There's no reason why extenstion jars shouldn't be in a separate directory.
But of course, free jvm's may support none of these options, so where's the other layer that would handle converting between the two? Is `java', `javac' and/or 'javadoc' supposed to be wraper scripts themselves?
difference is, that I propose to add had dependecies (package manager level) and your scritp does it automagically, when jars are installed, right?
I don't understand what you mean here.
Currently, our system has several major flaws.
1.) The first is not picking up dependencicies for a given jar file (i.e., what could usually be found in a jar's Class-Path in the manifest). You propose flat files for each jar. I think symlinks offer more over and are easier to update than sed and grep on a file, but whatever, the important thing is that we both want this solved.
2.) The second is not providing enough virtual provides. Take jdbc-stdext-ext again as an example. This is only needed by pre 1.4 jvm's, but the 1.4 jvm's don't have a virtual provides for this package. Similarly, we have a virtual provides for jaxp_parser_impl provided by crimson, xerces-j2, etc., but the 1.4 jvm's don't have a virtual provides for this either. At one time it was decided not to do this because xerces was better, but in this case, I think the correct solution would have been to let update-alternatives handle it (where xerces-j2 would get the highest priority) but definitely xerces-j2 should not be required with a 1.4 jvm.
I have no idea if this answers your question, but HTH.
If I promise to build in all your functionality (JVM including,
CLASSPATH ordering for ant) into a script, do you think we can agree
on doing it all at runtime? And putting in a way to enforce JVM
depedencies which can configured to work around (and use a non
packaged JVM)?
We may have already done some of this in the java-functions script (which is about 300 lines). You seem to want to do a complete rewrite and maybe this is in order, but I don't know.
Yes. I would also like to consider your 'shell functions' based idea, but that would mean that every startscript needs to be #!/bin/sh, instead of using a generic script, which outputs a string. An idea would be to add a wrapper script, which just calls the functions in the right order and one 'function' script, which just includes the function and which can be sourced.
Exactly (wrt the dual functions/startup wrapper idea). But if you don't plan on using /bin/sh, what do you plan on doing with the output string?
We may want to use something akin to /etc/lsb-release when we have such standard functionality in place.
-- Sincerely,
David Walluck <[EMAIL PROTECTED]>
signature.asc
Description: OpenPGP digital signature
