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.
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.
--
John
