From derby-dev-return-77902-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue May 04 08:35:07 2010 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 43305 invoked from network); 4 May 2010 08:35:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 May 2010 08:35:07 -0000 Received: (qmail 24916 invoked by uid 500); 4 May 2010 08:35:07 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 24714 invoked by uid 500); 4 May 2010 08:35:07 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 24707 invoked by uid 99); 4 May 2010 08:35:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 08:35:06 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.18.6.21] (HELO gmp-eb-inf-1.sun.com) (192.18.6.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 08:34:56 +0000 Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o448YWIJ001592 for ; Tue, 4 May 2010 08:34:33 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1V00700ZQVXG00@fe-emea-13.sun.com> for derby-dev@db.apache.org; Tue, 04 May 2010 09:34:18 +0100 (BST) Received: from [129.159.139.223] ([unknown] [129.159.139.223]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1V00759ZT5GC80@fe-emea-13.sun.com> for derby-dev@db.apache.org; Tue, 04 May 2010 09:34:18 +0100 (BST) Date: Tue, 04 May 2010 10:34:11 +0200 From: Kristian Waagan Subject: Re: Change the behavior of PropertySetter? In-reply-to: <4BDF8331.600@gmail.com> Sender: Kristian.Waagan@Sun.COM To: derby-dev@db.apache.org Message-id: <4BDFDC03.2070002@Sun.COM> References: <4BDEB47E.8060605@Sun.COM> <4BDF8331.600@gmail.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 X-Virus-Checked: Checked by ClamAV on apache.org On 04.05.10 04:15, Bryan Pendleton wrote: >> 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. > > What is an "invalid installation" in this description? > > In general, your proposal sounds fine to me, I'm just trying to > understand > what sort of invalid installations the build tool is uncovering and why. Hi Byran, The two problematic installations I have stumbled across lately, where I tried to build Derby and it failed due to incorrect compilation classpaths, were: a) A JDK 1.4 was uninstalled, but because a custom jar had been placed into the jre/lib/ext directory, the directory structure wasn't removed. This caused an empty classpath. b) A gcj-installation on a Linux distro was picked up as the 1.5 JDK, but even though it contained a jre/lib (with rt.jar), it didn't have any executables (java or javac). As far as I can see, the directory was a valid part of an installed package (maybe even installed by default on a fresh install). These were picked up because they met the following requirements: 1) The base directory contained the target JDK version (i.e. 1.5). 2) The base directory contained the directories jre/lib. My point is that the new algorithm has a few more requirements, and it didn't pick up these installations for a reason. Therefore, if the new algorithm does the job by fulfilling the minimal JDK requirement, I suggest to skip the old algorithm. However, if the new algorithm fails to locate a JDK, we can run the old one - it may manage to pick up one that can be used. More along the lines of what Rick wrote in his reply, both of these algorithms will fail for some JDKs. This means that if we want almost all of our casual developers / hackers to be able to successfully run 'ant all buildjars', we will have to extend PropertySetter. Regards, -- Kristian > > thanks, > > bryan