Hi Myrna,
Just to confirm what Kristian has said, this is how it is supposed to work:
1) The out-of-the-box experience, which should work for most users is
this: Do nothing. That is, don't even create an ant.properties. The
Derby build should successfully figure out where your JDKs live and
automatically construct the lists of jar files which the build needs in
order to correctly compile the jdk14-specific, java5-specific, and
java6-specific code.
2) However, that may not work for you if you have put the JDKs in custom
locations on your machine which the build can't find. In that case, you
should be able to tell the build where the JDKs live by setting the
following variables in your ant.properties:
j14lib
j15lib
j16lib (in the future)
In this situation, the build should be able to construct the lists of
jar files it needs just from the pointers provided by these variables.
Note that you should not need to set dontAutosetProps. This sounds like
your situation, Myrna. If this doesn't work for you, please help us
understand what is broken so that we can fix this.
3) At the fringes will be people with very special environments, e.g.,
people who use JDKs supplied by vendors which the Derby build doesn't
understand. Currently, Derby understands the structure of the Sun, IBM,
and Apple JDKs. These people should be able to painfully and explicitly
spell out what the jar file lists are by setting the following variables
in their ant.properties:
java14compile.classpath
java15compile.classpath
java16compile.classpath (in the future)
Again, even these people should not have to set dontAutosetProps.
We would like to get everybody running on one of the above schemes so
that we can remove the support for dontAutosetProps. Right now, it is
causing confusion for people who need to extend our build scripts.
Hope this is more clear. Please let us know if option (2) doesn't work
for you.
Thanks,
-Rick
Kristian Waagan wrote:
Myrna van Lunteren wrote:
Just to make sure I can continue to work as I have been; I have no
desire to let my environment be set to a standard setup.
I have been using my own name and directory locations for the (ibm
*and* sun) jvms, much shorter than the default names, and I like/need
to be able to switch around at will, and the automation put in place
so far doesn't work for me.
Please confirm that dontAutosetProps will remain in place?
Myrna,
I won't remove it. According to the item list Rick wrote, there will
be a poll before anything is removed and he indicated there were
wrinkles left that needed to be straightened out.
That said, I'm still having trouble understanding what doesn't work.
Can you help me understand?
For instance, I can compile Derby with the following ant.properties,
using non-standard directories:
$ cat ~/ant.properties
j15lib=/private/kw160128/tmp/vms/vm/jre/lib
j14lib=/private/kw160128/tmp/vms/o/jre/lib
jdk16=/usr/local/java/jdk1.6
$
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.
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.
Right now I can think of using one of these;
a) Set the java1Xcompile.classpath variables
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
d) Introduce dependencies in the build scripts
Please note that I am not trying to force a change here, I just want
to bring out problems so we can fix them.
regards,
