esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Tests failing to run with "mvn clean test" - trunk/server revision 886861
Date Mon, 07 Dec 2009 00:37:19 GMT
I took a look, and it is the same error but I don't think it's
necessarily the same issue. That error seems to pop up whenever the
system can't connect to a database for any reason. So, it happens when
I remove Derby from the pom.xml file entirely, for example.

I was able to completely clear out the ~.m2/ repository on my local
machine and do a "mvn clean test" from scratch. 20 minutes later, I
have a terminal output that looks almost exactly like except that
the tests still run fine on my local machine.

So I'm wondering if there really is something going on with Hudson. I
don't really understand what it is doing. Maybe I need to get an
account and dig into it.

Is it possible that we have a property set on the Hudson server that
makes the Boot.scala try to use PostgreSql? Would be a property
"use_prod_psql" or "use_local_psql".


On Sun, Dec 6, 2009 at 4:43 PM, Richard Hirsch <> wrote:
> Take a look at this thread from the lift mailing list:
> Maybe, the problem is somewhere else -although I don't why it would
> work locally but not on Hudson..
> D.
> On Sun, Dec 6, 2009 at 11:37 PM, Ethan Jewett <> wrote:
>> Maybe *I* am still using the old Derby Jar file, but then the
>> in-memory db shouldn't work. I'll give it a go after clearing out my
>> m2 directory this evening, hopefully.
>> Ethan
>> On Sunday, December 6, 2009, Richard Hirsch <> wrote:
>>> Trying to figure what the problem is...
>>> Maybe, we are still using the old derby jar file...
>>> D.
>>> On Sun, Dec 6, 2009 at 9:20 PM, Ethan Jewett <> wrote:
>>>> Hmmm, that is strange. I didn't notice that at first, but it is
>>>> happening on my machine as well. Interestingly, the tests run fine on
>>>> my machine.
>>>> How is Hudson actually running these tests? Is it different from a
>>>> "mvn clean test" in some way?
>>>> Ethan
>>>> On Sun, Dec 6, 2009 at 1:58 PM, Richard Hirsch <>
>>>>> Just deployed on Hudson
>>>>> ( and we
>>>>> still have the error.
>>>>> There is a warning regarding the new derby version that could be the
>>>>> cause of the problem.
>>>>> [WARNING] POM for 'org.apache.derby:derby:pom:' is
>>>>> invalid. It will be ignored for artifact resolution. Reason: Not a
>>>>> v4.0.0 POM. for project org.apache.derby:derby at
>>>>> /export/home/hudson/.m2/repository/org/apache/derby/derby/
>>>>> @Ethan: is the reference in the pom.xml file correct?
>>>>> D.
>>>>> On Sun, Dec 6, 2009 at 6:29 PM, Ethan Jewett <>
>>>>>> BTW, in case anyone is interested, I used this blog as my jumping-off
>>>>>> point into Derby and H2 documentation:
>>>>>> Ethan
>>>>>> On Sun, Dec 6, 2009 at 11:27 AM, Ethan Jewett <>
>>>>>>> I've posted a patch to issue 142
>>>>>>> (  The patch
>>>>>>> the version of Derby we are using in pom.xml and switches the
>>>>>>> databases to run in memory.
>>>>>>> I'm not running H2 because I couldn't figure out immediately
how to
>>>>>>> get Lift to build the DB in H2 properly, so I was getting test
>>>>>>> failures due to missing tables.
>>>>>>> Hopefully this will solve the Hudson issue.
>>>>>>> Ethan
>>>>>>> On Sun, Dec 6, 2009 at 7:57 AM, Richard Hirsch <>
>>>>>>>> @Ethan - I'm asuming that is the problem on Hudson. Would
be great if
>>>>>>>> we can solve this.
>>>>>>>> Could you take a look and see if you find the maven confíguration
>>>>>>>> allow in-memory usage. I looked but didn't find anything.
>>>>>>>> On Fri, Dec 4, 2009 at 7:52 PM, Ethan Jewett <>
>>>>>>>>> Would that fix the issue with Hudson as well? I'll look
into that a bit.
>>>>>>>>> Ethan
>>>>>>>>> On Fri, Dec 4, 2009 at 12:18 PM, David Pollak
>>>>>>>>> <> wrote:
>>>>>>>>>> On Fri, Dec 4, 2009 at 9:32 AM, Ethan Jewett <>
>>>>>>>>>>> I'm not following.
>>>>>>>>>>> My local repo exactly matched the trunk branch
as of when my email was
>>>>>>>>>>> sent. I'd deleted my entire local repo and checked
out from Apache SVN
>>>>>>>>>>> multiple times while trying to debug, so any
local changes should be

View raw message