Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 19 Nov 2007 20:45:08 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Automatic setting of compiler classpath properties at build time
In-reply-to: <4741C7FF.7020907@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7zlxauiij.fsf@ugle.localdomain>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <474199FA.9030800@sun.com>
 <wjo8abpa88z3.fsf@khepri41.norway.sun.com> <4741C7FF.7020907@sun.com>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (usg-unix-v)

Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> Rick Hillegas <Richard.Hillegas@Sun.COM> writes:
>>
>>   
>>> I have checked in some build logic which automatically sets the
>>> compiler classpath properties. This is part of the work on DERBY-3117
>>> and the goal,  ultimately, is to have a Derby build script which works
>>> out of the box without any customizing of ant.properties.
>>>     
>>
>> Hi Rick,
>>
>> I tested the patch on Solaris 10 and on Solaris Express Community
>> Edition snv_77, with JDK 1.4 and JDK 5 installed on their default
>> locations and JAVA_HOME unset, but both attempts failed because the JDK
>> 1.4 installation is not found.
>>
>> I think the problem lies in that the Solaris packages install the
>> different JDK versions to these two locations:
>>
>>  /usr/jdk/j2sdk1.4.2_06
>>  /usr/jdk/jdk1.5.0_13
>>
>> However, j2sdk1.4.2_06 is a symlink to ../j2se and jdk1.5.0_13 is a
>> symlink to instances/jdk1.5.0, so when the symlinks are followed, they
>> don't seem to be installed in neighbour directories. Unless you
>> immediately see how to solve this, I'll take a look at it tomorrow.
>>   
> Thanks, Knut. I think that the instructions in BUILDING.txt say you
> you have to set JAVA_HOME. Removing that extra bit of setup might be a
> useful next step, but isn't covered by this change.

OK, I should have read BUILDING.txt first, but I still see the problem
when I set JAVA_HOME to one of:

  /usr/jdk/latest
  /usr/jdk/jdk1.5.0_13
  /usr/jdk/instances/jdk1.5.0

In all three cases, /usr/jdk/instances/jdk1.5.0/jre is reported as
java.home by "ant -diagnostics" (which is the same as it reports if I
don't set JAVA_HOME). So it seems like the JDK resolves the symlinks for
us before we even see it.

> However, you bring up an interesting case: What if the user sets
> JAVA_HOME not to the symlink but, instead, to the directory that it
> points at. On my Macbook the symlinks end up pointing at JDKs that
> are, nevertheless, parked next to each other. That doesn't seem to be
> the case in your Solaris installation. I don't have a smart heuristic
> for what to do if the JDKs don't live next door to each other. If you
> would like to noodle about this problem, that would be great.

I'll do that. I think we could get around the problem by having an extra
check if the property setter didn't find one of the JDKs, and if
${os.name}=="SunOS", we then look for JDK 1.4 under /usr/jdk and for JDK
5 (or later) under /usr/jdk/instances.

-- 
Knut Anders