Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Fri, 04 Jun 2010 09:26:54 +0200
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: Building Derby on MacOS X
In-reply-to: <AANLkTimV3XQY20uIRTn2buWRSrbpLpnusqnFNQ1aXn2F@mail.gmail.com>
Sender: Kristian.Waagan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4C08AABE.5010004@Sun.COM>
References: <AANLkTimV3XQY20uIRTn2buWRSrbpLpnusqnFNQ1aXn2F@mail.gmail.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
 rv:1.9.1.8) Gecko/20100412
 Lightning/1.0b1 Thunderbird/3.0.3

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,
-- 
Kristian

>
> Thanks in advance.
>
> Brett