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
trunk/java/engine/org/apache/derby/iapi/types/build.xml.
Hope this helps,
-Rick
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.
