ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian McFarland <...@neo.com>
Subject Re: Build failure on OS X (from anoncvs checkout)
Date Fri, 17 May 2002 21:01:45 GMT
Hiya,

On Friday, May 17, 2002, at 01:36  PM, Steve Loughran wrote:
>>>> You should make them give you an Xserve.
>>>
>>
>> See: http://www.apple.com/xserve/ (A very nice little 1U unit, with up
>> to .48TB storage, and 1 to 2  1GHz procs. New this week.)
>
> If apple were to donate one to Apache, I am sure that use would be made 
> of
> it. Hey, if they were to donate any of those fancy laptops like yours 
> I'm
> sure use would be made of them too, especially since my 3 year old 
> pII/300
> notebook died from all the excitement of spending the week up in the
> spiritual home of windows, and is now a nice LCD with a dead motherboard
> attached, and hard disk I need to gain access to, somehow.
>

Erk. What fun. Well, if Apple expresses interest in providing one, tell 
them I'd like one to run www.javaosx.com on, too. ;-)

>>
>> Mine's also a 2-proc box, which is probably good as there's a chance it
>> will expose any potential threading/sync issues.
>
> always good
>
>>>> Ah... perhaps. I suppose I should look more carefully at what I'm
>>>> checking out. ;-) How are the versions set up?
>>>
>>> The main branch...
>> * snip *
>>
>> Ok, I checked out ANT_15_BRANCH, and got the same build failure on test
>> 21:
>>
>> Testcase: test21(org.apache.tools.ant.taskdefs.AvailableTest):  FAILED
>> expected:<true> but was:<null>
>> junit.framework.AssertionFailedError: expected:<true> but was:<null>
>
> do you have a debugger on your PPC? could you, like step into tests to 
> see
> why things fail?
>

Debugger? Debuggers are for the weak! (That's what println is for. =-) 
Yeah, I have jdb on here.

> most tests call a build file and validate properties and things. Test 21
> runs
>
> etc/testcases/taskdefs/available.xml of which the relevant test is
>
>   <target name="test21">
>     <available property="test" ignoresystemclasses="true"
>                classname="java.awt.Graphics"
> classpath="${java.home}/lib/rt.jar:${java.home}/lib/classes.zip"/>
>   </target>
>

Yes, that probably is the problem, since there is no 
$JAVA_HOME/lib/rt.jar or $JAVA_HOME/lib/classes.zip. I can pretty much 
assure you that java.awt.Graphics is available, though! Use it all the 
time. I think the OS X Java runtime just includes most of the runtime 
stuff inside the binary. As a result, I guess I'm not sure why this 
fails, though. If I do this, for example, I get what I expect:

[localhost:~/Projects/osxize/test] imf% java -classpath 
${JAVA_HOME}/lib/rt.jar:${JAVA_HOME}/lib/classes.zip:../build/osxize.jar 
com.neo.util.mac.AppPackager
Neo Development Utilities for Mac OS X
App Packager

Usage: java -jar osxapp.jar [args]
       -m mainclass
       -o outputdir
       -n name (human-readable)
       -s shortname (machine-readable)
       -c creator
       -t type
       -r developmentregion
       -i icnsfile
       -addjar jarfile containing your java classes (can have more than 
one)

For more information about this package, visit our website at:
http://www.neo.com/

[localhost:~/Projects/osxize/test] imf%


Here's what's in lib on OS X, in case you were wondering.

[localhost:~/Projects/osxize/test] imf% ls $JAVA_HOME/lib/
Xusage.txt                              glconfigurationlist.properties
audio                                   ir.idl
cmm                                     jvm.cfg
content-types.properties                jvm.hprof.txt
dt.jar                                  orb.idl
ext                                     security
flavormap.properties                    swing.properties
fonts                                   tzmappings
[localhost:~/Projects/osxize/test] imf%

I'll try poking around with JDB at some point here. I never use it, so 
I'm not very efficient with it, so it might take a little while.

>
> so the failure could just be that the runtime is in a different place, 
> and
> we need to change the test. Seem likely?
>
>>> What I see now is that I'm unable too bootstrap Ant there because I'm
>>> not running in a graphical mode, at least this is my interpretation of
>>>
>>> kCGErrorFailure : initCGDisplayState: No display interlock
>>>
>>> Any idea how I could solve this?
>>
>> Hrm... That's an interesting one. Um... Never tried to run headless
>> before to do this. Lemme try it myself....
>>
>> This may take some work. When Iog in as myself over ssh, I still have
>> access to my window server, 'cause I'm logged in. I'll have to try this
>> by logging out, and logging in to my desktop from my laptop.
>
> Looks like someone still has to get the hang of running java headless. 
> dont
> worry, java1.3 on unix has the same problem in the imaging libs, hence
> various batik related issues.
>


Yeah, Macs don't like to be headless so much. They can be, but they 
don't like it. I think they are starting to address this (starting!) 
with Xserve and language patches for it. It does still need to have a 
framebuffer installed, though. Which is a shame. Would be nice to use 
that PCI slot for something more useful, or at least not have to pay for 
the card.

And no, Java pre 1.4 is completely brain-dead when it comes to rendering 
graphics without a framebuffer. Still part of that nasty 1.0 legacy, I 
think. AWT? Need I say more?

-Ian


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message