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: [jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby
Date Fri, 18 Jan 2008 16:15:34 GMT
Hi John,

Ant and the build logic are not for the faint of heart. I'm afraid I 
don't understand exactly what experiments you have run, but I will try 
to muddle through some advice here...

John Embretsen wrote:
> I ran into an issue with the property setter in relation to DERBY-1387 
> (JMX), see below...
> Rick Hillegas wrote:
>>> The property setter yields the output I have attached at the bottom.
>>> If I had very custom jar files (spread around in multipe dirs, not 
>>> in j1Xlib), and maybe a VM vender the property setter doesn't 
>>> recognize, I would specify java14compile.classpath, 
>>> java15compile.classpath and java16compile.classpath.
> I do not have "very custom jar files" in multiple dirs, and I my VM 
> vendor is Sun. What I do have, is j14lib and j15lib set in my 
> ant.properties file, and a patch which adds a required jar file to 
> java14compile.classpath in the file 
> tools/ant/properties/compilepath.properties.
This will not work. The compilepath.properties file is not read until 
after PropertySetter runs. This can be seen by looking at the 
setCompilerProperties target in the master build file. Once 
java14compile.classpath has been set (either in your ant.properties or 
by PropertySetter), ant will not let you override it. So ant ignores 
your setting in compilepath.properties.

The bottom line here is that you cannot "add" a jar file to 
java14compile.classpath later on. The property can only be set once 
during the build and it cannot be changed later on. That's just how ant 
works and I don't know anyone who isn't annoyed by this behavior.

What ant does let you do is construct classpaths from constituent pieces 
later on. One of the constituent pieces can be the jdk jar files 
(pointed to by the java1*compile.classpath variables). You can also add 
other legs to a classpath by adding in variables which we conventionally 
define in extrapath.properties. As an example of how to do this, take a 
look at the compile_types target in 

Hope this helps,
>>> Now, there is at least one other pitfall, and that is if you are 
>>> running lower level ant targets. One example is "ant client". The 
>>> dependencies for this target does not include the compiler property 
>>> setter task, and thus you will have to do something manually for 
>>> this to work.
> I am not running lower-level ant targets, I am running "ant all"...
>>> Right now I can think of using one of these;
>>> a) Set the java1Xcompile.classpath variables
> This resolves my issue.
>>> b) Call the property setter; ant setCompilerProperties client
>>>     (for custom directories, I believe you still need j1Xlib 
>>> variables set manually)
> >> c) Use higher-level targets
> Irrelevant; I'm using "ant all".
>>> d) Introduce dependencies in the build scripts
> It seems that ant has not loaded the contents of 
> tools/ant/properties/compilepath.properties at the time when the 
> PropertySetter runs into action. Since j14lib is set, it sets 
> java14compile.classpath based on what's in j14lib instead of what's in 
> compilepath.properties.
> So, parts of compilepath.properties is only used if the PropertySetter 
> is not used. Is this intentional?
> Note that my intention is to get rid of the requirement for the extra 
> jar file in the next version of the DERBY-1387 patch, so this won't be 
> an issue for long. I'm just mentioning this in case it might cause 
> trouble later on.

View raw message