db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Building Derby on MacOS X
Date Fri, 04 Jun 2010 13:03:42 GMT
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.


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,

View raw message