buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lacton <lac...@users.sourceforge.net>
Subject Re: [buildr] Java.tools_jar
Date Sat, 13 Sep 2008 12:25:37 GMT
On Fri, Sep 12, 2008 at 3:56 AM, Assaf Arkin <arkin@intalio.com> wrote:
> On Thu, Sep 11, 2008 at 1:50 PM, lacton <lacton@users.sourceforge.net> wrote:
>> When running 'rake spec', I get the following error.
>>
>> <quote>
>> /home/lacton/projects/buildr/trunk/tmp/src/main/java/UseApt.java:1:
>> package com.sun.mirror.apt does not exist
>>      import com.sun.mirror.apt.AnnotationProcessor;
>>                                ^
>>
>> 1)
>> RuntimeError in 'javac compiler should include tools.jar dependency'
>> </quote>
>>
>> My analysis is:
>> 1. 'java/compilers.rb' tries to add tools.jar to the class path by
>> adding "Java.tools_jar" to "dependencies".
>> 2. The Java module doesn't have a 'tools_jar' method since revision
>> 693281, so 'Java.method_missing' is called instead and a
>> Java::Tools_jar package is dynamically created.
>> 3. The CompileTask tries to compile with "javac -classpath
>> Java::Tools_jar".  This invalid classpath element is ignored and
>> compilation is done without tools.jar in the compiler classpath.
>> 4. The test case "it 'should include tools.jar dependency'" in
>> java_compilers_spec.rb fails because tools.jar is missing from the
>> compiler classpath.
>>
>> Is it the spec or the code that's wrong?
>
> Spec is correct, you want tools.jar included in the classpath,
> otherwise certain things break, annotations is one of them (used by
> the spec).

Thank you for this explanation.  I committed revision 694936 to comply
with the failing spec.

> Back in the days you had to add it explicitly, by calling
> Java.tools_jar, which turned out to be a nuisance because a) people
> forgot to do it, b) on some platform there is no tools.jar, so you get
> an empty result.
>
> So right now tools.jar is supposed to be included always by default,
> and Java.tools_jar should probably return something meaningful for
> bugwards compatibility so it doesn't break code that still uses it
> (when version < 1.4)

OK, I'll try to add some tests on that.

Lacton

Mime
View raw message