Hi Kristian,
Some comments inline...
Kristian Waagan wrote:
Hi,
The PropertySetter, whose responsibility it is to configure the
compile classpath(s) if the user hasn't, now has two algorithms to
detect JDK installations:
(1) JAR inspection (newer)
(2) directory name filter (old)
Currently (1) is run first, followed by (2).
Lately, I have stumbled across a few environments where (2) causes the
Derby build to fail. The typical pattern is that (1) detects a valid
Java SE 6 installation, and then (2) picks up an invalid installation
of Java SE 5.0 or J2SE 1.4.
Would it make sense to run (2) only if (1) can't find the required
JDK(s)?
PropertySetter is a custom ant task. When it was first written,
PropertySetter tried to follow the ant model for setting properties: a
request to set a property was honored only if the property was not
already set. If the property was already set, then the attempt to
override it was silently ignored. I assume that PropertySetter continues
to behave this way but it's been a while since I was in there.
A) This behavior can be a little confusing to people who are not
familiar with ant's way of thinking. However, it continues to make sense
to me that an ant task should follow the ant conventions. I feel that
breaking the ant conventions would be even more confusing. What would be
even worse would be to follow the conventions sometimes, break them
sometimes, and not have a simple rule for figuring out when the
conventions apply.
B) PropertySetter is an attempt to gather up a set of heuristics, which
have been discovered by trial and error. It is an attempt to code these
heuristics in a language which
i) we all know and
ii) is more expressive and readable than ant's xml dialect.
I continue to think that it is easier to code the heuristics in Java
than in xml. However, PropertySetter is still too complicated. That is
largely because I had never solved a problem like this before I just
hacked the first increment together. Sorry. Since then several people,
yourself included, have made important contributions to this program. It
is now both more capable and more complicated. PropertySetter may have
reached the point where it needs a good re-write. A table-driven
approach might be attractive. It would be nice to see at a glance what
the outcome is for a given ( operatingSystem, jdkLevel ) coordinate.
I am happy with the changes you are suggesting, or even with a complete
re-write, provided that (A) and (B) are still satisfied.
In my opinion, 'ant all buildjars' should just work (to build
everything you still have to add JUnit).
Regular Derby developers with special build requirements can configure
the build process manually (they are probably doing this already).
What do people think?
Two caveats:
I) As with all changes to PropertySetter, it is best to get broad
developer feedback on your patches before committing them. It's easy to
break other people's build environments. I know. I've done it a lot.
II) I would appreciate it if you could hold off changing the Derby build
until after 10.6.1 is released.
As a side note, as people start building Derby with other JDKs, like
Harmony, OpenJDK or the FSF-one, I do expect some issues.
Also, I think Derby simply doesn't build with all of these...
A table-driven structure might make it easier to plug in more variants
like these.
Thanks,
-Rick
Regards,
