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