Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Mon, 03 May 2010 13:33:18 +0200
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Change the behavior of PropertySetter?
Sender: Kristian.Waagan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4BDEB47E.8060605@Sun.COM>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
 rv:1.9.1.8) Gecko/20100329
 Lightning/1.0b1 Thunderbird/3.0.3

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)?

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


Regards,
-- 
Kristian