db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: DERBY-516 patch review, pt. 1
Date Tue, 25 Oct 2005 21:59:11 GMT
On 10/24/05, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>  I confess I don't see the value in making compilation of this test class
> optional given that we have already voted to require JUnit as part of
> our build machinery.

I was quite concerned, though, when the first submission of a Junit
test failed to compile, failed to pass in the current test harness,
and failed (for me) to run outside of the test harness as provided.
This certainly amplified my -0 feeling towards it - make it optional
until we get it right. But you're absolutely right, the vote to
require Junit passed, so, let's at least get the patch to the point
where it doesn't break anything now and we can work on the details
later. :-)

I still currently cannot get the JDBCDriverTest class to compile. The
problem is that compile.classpath is not guaranteed to be a certain
level of jdk, and JDBCDriverTest needs to be compiled against JDK 1.3.
compile.classpath needs to be overridden in certain circumstances, for
instance when building with J2ME support, with Gump, or on Mac OS X,
and it is not guaranteed to be the same as java13compile.classpath.
The problem I'm currently having can be fixed by simply changing
$[compile.classpath} in the <classpath> element of the <javac> in the
build.xml of tests/compatibility to ${java13compile.classpath}

Also, whomever is going to commit the patch needs to be sure that an
empty master file is created in functionTests/master. My patch program
skipped over the empty diff without creating an empty patch file.

> > 7 - The default values in testScript.xml for the locations of the
> > JVMs are not applicable to Mac OS X (an itchy platform for me). I'll
> > follow up on this later.
> If you can tell me what to use here, I'll make the changes.

I'll get back to you on that. The structure of the JDK directories is
different on Mac OS X than on Windows, Solaris or Linux, and I believe
the same is true for some other platforms. It looks like I can work
around it by directly setting some of the properties set at the
beginning of the file in my ant.properties.

If you can fix the first problem listed above, and resend the patch,
then I'm ok with David or someone else committing it. Or, I can commit
the patch as I have it modified in my local view with the one line


View raw message