This is an interesting issue. I was running a hackint0sh back in the day (basically Mac OS on a normal PC) and if I recall correctly, Derby compiled fine. I don't even recall having to make any special steps to get it to compile, but I might be mistaken.
Just keep in mind though that Java on Macs runs on Apple's JVM, which might (it shouldn't, but might) have some strange behavior sometimes. Tiago ----- Original Message ---- From: Rick Hillegas <[email protected]> To: [email protected] Sent: Fri, 4 June, 2010 14:03:42 Subject: Re: Building Derby on MacOS X Hi Brett, As Kristian says, we understand the importance of a clean build out-of-the-box and we would appreciate your help in isolating why the build fails in your environment. The Derby build is tricky because the engine must run on CDC FP/1.1, jdk1.4, Java 5, and Java 6. I have been building Derby on my Macbook Pro for several years now, using both the Java 5 and the Java 6 compilers. Thanks for your help in improving this. Regards, -Rick Kristian Waagan wrote: > On 04.06.10 05:24, Brett Wooldridge wrote: >> I'm looking for a little guidance on building Derby on OS X. >> >> I checked out the trunk from SVN, and followed the build instructions: >> >> http://svn.apache.org/viewvc/db/derby/code/trunk/BUILDING.html?view=co >> >> While seemingly simple, I've run into a series of issues. First attempt >> failed quickly with deprecation errors. So, I created a local.properties >> file and set "deprecation=off". That fixed that. >> >> Subsequently, I get org.apache.xpath does not exist. While the source tree >> seems to contain these in tools/java, the build doesn't seem to use them >> directly. Adding them explicitly to ant.properties get's further >> >> java14compile.classpath >> java15compile.classpath >> java16compile.classpath >> >> Though first I had to set "printCompilerProperties=true" to capture the >> relevant full paths. >> >> Why doesn't Derby just use these by default? What is the point of the nice >> classpath detection code for OS X if ultimately you have to override the >> classpath's completely in ant.properties? >> >> Finally, I've ended up with a simple compilation failure: >> >> compile_iapi_jdbc_stmt: >> [javac] Compiling 1 source file to >> /Users/brettw/Documents/dev/derby-trunk/trunk/classes >> [javac] >> /Users/brettw/Documents/dev/derby-trunk/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:43: >> org.apache.derby.iapi.jdbc.BrokeredStatement is not abstract and does not >> override abstract method isPoolable() in java.sql.Statement >> [javac] public class BrokeredStatement implements EngineStatement >> [javac] ^ >> [javac] >> /Users/brettw/Documents/dev/derby-trunk/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:563: >> isClosed() in org.apache.derby.iapi.jdbc.BrokeredStatement cannot implement >> isClosed() in java.sql.Statement; attempting to assign weaker access >> privileges; was public >> [javac] protected boolean isClosed() throws SQLException { >> [javac] ^ >> [javac] 2 errors >> >> This is the same error that was flagged when I loaded the source up in >> Eclipse. I thought my Eclipse build environment wasn't setup right, so >> surely the official ant build would work. >> >> So, I'm kindof stuck. Some guidance would be greatly appreciated. >> >> By way of small criticism (and really I do love Derby), it should be a goal >> of an open source project to get a successful build (on all platforms) by >> simply performing (a) svn co ..., followed by (b) ant. > > Hi Brett, > > We're aware of this issue, and have done work in this area for some time. > > It would be helpful if you could take a step back to help us debug why the > build isn't working: > 1) Remove your ant.properties file and the local.properties (and any > arguments you are passing to ant) - it may be wise to keep them around in > case you need them later > 2) Save the output (to file, or just use less) from when you invoke ant with > -DprintCompilerProperties=true > 3) Post the output from under the section called 'printCompilerProperities' > (down to 'jsr169stubs') > > I believe we have at least one community member developing on a Mac, so if > you provide this information maybe he can give some helpful feedback. > I have also built Derby on a Mac Mini without problems, so I don't know > what's different in your case. > > Based on your final compilation failure, it looks like the wrong JDK library > version is used. > And for the sake of clarity, is your source tree unmodified? > > > Regards,
