db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Change the behavior of PropertySetter?
Date Mon, 03 May 2010 11:33:18 GMT

The PropertySetter, whose responsibility it is to configure the compile 
classpath(s) if the user hasn't, now has two algorithms to detect JDK 
  (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)?

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?

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


View raw message