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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
