Daniel John Debrunner wrote:
Rick Hillegas wrote:
The place to add support for additional platforms/vms would be
trunk/java/build/org/apache/derbyPreBuild/PropertySetter.java The
class has a pretty extensive header comment explaining what the class
does--but please let me know if the header is unclear.
At line 207 (just after this code)
if ( j14lib != null ) { setClasspathFromLib( J14LIB, j14lib ); }
if ( j15lib != null ) { setClasspathFromLib( J15LIB, j15lib ); }
should the task return if both j14lib and j15lib were set? E.g.
if (j14lib != null && j15lib != null)
return;
Other it seems the setting of the classpath will be overwritten in the
platform specific code and for me the build fails because the vm
(Apache Harmony) is not recognized, even though I've defined j14lib &
j15lib.
Thanks for the quick test-drive, Dan. I don't understand what you're
seeing. If j14lib and j15lib were set, then PropertySetter should have
set each corresponding compile.classpath property to be equal to the
list of jars in the indicated library. Are there in fact jar files in
those directories? Is the file extension on the jar files ".jar"? Maybe
the JarFilter inner class isn't smart enough to find your jar files.
Could you list out what's in those directories?
If the PropertySetter didn't manage to set the compile.classpath
properties, then PropertySetter should have aborted the build and
printed out its environment. Could you attach that printout?
In setForMostJDKs() this code exists:
String sunJavaRoot = javaHome + File.separator + ".." +
File.separator + "..";
I think this should be using File.getParent() and not "..".
Technically ".." is not part of the Java specification. From the
various comments on the list it seems there is some assumption about
where JVM's live in relationship to each other, but these doesn't seem
to be documented in the code.
Dan.
Thanks for pointing out this improvement.
Regards,
-Rick
