db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: 'Issue' with Eclipse
Date Mon, 16 Mar 2009 16:34:47 GMT
Myrna van Lunteren wrote:
> On Mon, Mar 16, 2009 at 7:05 AM, Tiago Espinha <tiago@espinhas.net> wrote:
>> Knut Anders Hatlen wrote:
>>> Tiago Espinha <tiago@espinhas.net> writes:
>>>> Hey guys, I'm back.
>>> Hi, and welcome back! :)
>>>> Perhaps some of you still remember me from last year. I applied to
>>>> GSoC on the Apache Derby project and unfortunately ended up not
>>>> getting picked. I still hanged around for a while but I ended up
>>>> leaving at some point. This year I'm back and I'm applying for GSoC
>>>> again :)
>>>> Right now I'm in a bit of a stalemate with an annoying issue that's
>>>> bothering me. I followed all the steps to build Derby's code and to do
>>>> the testing. I am able to build it now and I can also run derbyall
>>>> with no issues (or close to no issues since derbyall skipped
>>>> derbynetmats, jdbcapi and jdbc20). The problem that I am stuck with is
>>>> actually Eclipse-related.
>>>> I have sort of imported Derby into Eclipse and I am getting 1559
>>>> errors. With a quick glance through some of the errors, I notice that
>>>> some of them come from jdbc4 classes, like
>>>> LogicalCallableStatement40.java . On this one I get for example "The
>>>> method setRowId(int, RowId) is undefined for the type
>>>> CallableStatement" and many more errors.
>>> I don't use Eclipse myself, so I don't know how you can fix it, but my
>>> guess is that you have configured it to use Java 5 libraries, so that it
>>> doesn't find some of the new methods in JDBC 4.0. The warning you see in
>>> LogicalCallableStatement40 is because it contains a line which looks
>>> like this:
>>>    getPhysCs().setRowId(arg0, arg1);
>>> getPhysCs()'s signature says that it returns a
>>> java.sql.CallableStatement, but in Java 5 that class didn't have a
>>> setRowId method and therefore you see the warning.
>>> If you use the Java 6 libraries instead, this warning should go
>>> away. Unfortunately, you'll probably get other warnings in the JDBC 3.0
>>> classes instead. (Like complaints because the non-abstract class
>>> LogicalCallableStatement implements java.sql.CallableStatement but
>>> doesn't implement the setRowId method.)
>> Hi,
>> I think you are most likely correct about the Java 5 libraries, but the
>> weird thing is that the libraries are actually set for Java 6, so that
>> shouldn't be it. It doesn't matter anyway, I just switched over to Netbeans.
>> it should be less messy :)
>> Tiago
> If you've switched to netbeans, this info may be like mustard after
> the meal (sorry - non-English proverb, I hope it makes sense)...But
> here is my 2 c:
> You can actually set up eclipse to 'add' the libraries for the other
> jdks. I have 3 jdks loaded in my eclipse source derby project.
> However, the Derby build process is pretty complex - at least it used
> to be - so I've configured eclipse to never build...(although I have
> done a right click on the build.xml and built that way at some point
> in the past). Normally I build outisde eclipse and run within.
> Myrna
> Myrna
Hehe, mostard na de maaltijd, I have some dutch friends :)

Anyway, I don't think it is mustard after the meal. The truth is that 
the tutorial available on the wiki is for both Eclipse and Netbeans 6.0 
. At this point we're on Netbeans 6.5 and as so, I'm running into some 
issues. So I may ultimately give up and end up rolling back to the 
initial Eclipse plan. Either way I think I'll update the wiki with my 
experience since that page 
(http://wiki.apache.org/db-derby/BuildingDerby) is already somewhat 

I don't overly want to build within the IDE, but I want to have no 
errors, so Eclipse would work fine for the task.


View raw message