db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Automatic setting of compiler classpath properties at build time
Date Mon, 19 Nov 2007 19:06:22 GMT
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.


View raw message