Missing Jakarta jar, was: Automatic setting of compiler classpath properties at build time

[Rick Hillegas <Ri...@Sun.COM>]

Vemund Ostgaard wrote:
>
>>> I tried it out in my sandbox Rick, and it worked fine except for one 
>>> thing that probably isn't related to your changes.
>>>
>>> The first time I do "ant all" after having done "ant clean" or "ant 
>>> clobber", the build fails when compiling
>>>
>>> junitcomponents:
>>>    [javac] Compiling 1 source file to 
>>> /usr/local/cluwin/vo136787/derby/source/trunk/classes
>>>    [javac] Compiling 11 source files to 
>>> /usr/local/cluwin/vo136787/derby/source/trunk/classes
>>>    [javac] 
>>> /usr/local/cluwin/vo136787/derby/source/trunk/java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java:35: 
>>> package org.apache.oro.text.regex does not exist
>>>    [javac] import org.apache.oro.text.regex.*;
>>>
>>> As far as I can understand, for some reason it cannot find the 
>>> jakarta-oro-2.0.8.jar, but it is in my tools/java/ directory where 
>>> it is supposed to be. When I do "ant all" again, it works, but it 
>>> fails the same way every time I have done clean or clobber before. 
>>> Any idea?
>>>
>>> Vemund
>> Hm. Could you try backing up your subversion client to just before my 
>> submission (596304) and re-run the experiment? 
> I get the same behavior with pre-596304 revisions.
>> Also, could you attach your ant.properties?
> Right now it looks like this:
>
> # autosetProps=on
> jdk16=/usr/local/java/jdk1.6
> j14lib=/usr/local/java/jdk1.4/jre/lib
> j13lib=/usr/local/java/jdk1.3/jre/lib
> proceed=false
> sane=false
> debug=false
>
> Vemund
One thing that's puzzling to me is why the build is trying to compile 
Sed.java (used by the old test harness) in the target that compiles 
support for our junit harness. According to the build output, the error 
is raised in the second javac block of junitcomponents. That block 
doesn't directly try to compile Sed and the classpath doesn't include 
the jakarta jar.

Perplexed,
-Rick

Re: Missing Jakarta jar, was: Automatic setting of compiler classpath properties at build time

[Vemund Ostgaard <Ve...@Sun.COM>]

Rick Hillegas wrote:
> One thing that's puzzling to me is why the build is trying to compile 
> Sed.java (used by the old test harness) in the target that compiles 
> support for our junit harness. According to the build output, the 
> error is raised in the second javac block of junitcomponents. That 
> block doesn't directly try to compile Sed and the classpath doesn't 
> include the jakarta jar.
>
> Perplexed,
> -Rick
Turns out I had a custom junit-runner lying around in the 
java/testing/org/apache/derbyTesting/junit/ directory that I had forgot 
about. This runner had a reference to 
org.apache.derbyTesting.functionTests.suites.All, which caused the chain 
of events leading to my problem. So, case closed. Thanks for putting me 
on the right track.

Vemund