db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Change the behavior of PropertySetter?
Date Tue, 04 May 2010 12:55:18 GMT
Kristian Waagan wrote:
> 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.
Hi Kristian,

I think that the following goal is more or less well defined and 
testable, although even it evolves more rapidly than I like. I think we 
can attain it:

a) A Derby build that works without tweaking on out-of-the-box 
installations of some set of ( operatingSystem, jdkVendor ) combinations.

In contrast, I would put limited effort into the following goal. I feel 
that this second goal is poorly defined, hard to test, and evolves too 
rapidly:

b) A Derby build that works without tweaking for all of our casual 
developers/hackers.

My $0.02,
-Rick
>
>
> Regards,


Mime
View raw message