esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Tests failing to run with "mvn clean test" - trunk/server revision 886861
Date Thu, 10 Dec 2009 12:02:42 GMT
oops.

Thanks. That wasn't intended but it is good to know that the option exists.

Can you please change it back and I'll do a new deployment tomorrow.

D.

On Thu, Dec 10, 2009 at 11:18 AM, Vassil Dichev <vdichev@apache.org> wrote:
> Looks like you configured not only the test DB, but also the main DB
> to run from memory, which means that on every restart you get a clean
> DB and need to sign-up again and again. You can also observe the same
> issue on the new Stax deployment. I assume this wasn't intended, so I
> guess nobody will mind if I fix it.
>
>
> On Mon, Dec 7, 2009 at 6:55 PM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>> just set "clean compile" to the maven options
>>
>> On Mon, Dec 7, 2009 at 5:05 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>>> Woohoo! You just made my morning. :-)
>>>
>>> What did you do?
>>>
>>> On Mon, Dec 7, 2009 at 6:58 AM, Richard Hirsch <hirsch.dick@gmail.com>
wrote:
>>>> The build is now working successfully - with tests.
>>>>
>>>>  http://hudson.zones.apache.org/hudson/job/ESME/41/
>>>>
>>>> On Mon, Dec 7, 2009 at 9:01 AM, Richard Hirsch <hirsch.dick@gmail.com>
wrote:
>>>>> It looks like the Hudson tests are using the Derby Driver.
>>>>> Unfortunately, I can't see the derby log in order to see exactly what
>>>>> is happening.
>>>>>
>>>>> D.
>>>>>
>>>>> On Mon, Dec 7, 2009 at 1:37 AM, Ethan Jewett <esjewett@gmail.com>
wrote:
>>>>>> 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
>>>>>> http://hudson.zones.apache.org/hudson/job/ESME/38/console 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".
>>>>>>
>>>>>> Ethan
>>>>>>
>>>>>> On Sun, Dec 6, 2009 at 4:43 PM, Richard Hirsch <hirsch.dick@gmail.com>
wrote:
>>>>>>> Take a look at this thread from the lift mailing list:
>>>>>>> http://groups.google.com/group/liftweb/browse_thread/thread/7984c37a4e79dc12
>>>>>>>
>>>>>>> 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 <esjewett@gmail.com>
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 <hirsch.dick@gmail.com>
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 <esjewett@gmail.com>
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 <hirsch.dick@gmail.com>
wrote:
>>>>>>>>>>> Just deployed on Hudson
>>>>>>>>>>> (http://hudson.zones.apache.org/hudson/job/ESME/35/console)
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:10.5.1.1:compile'
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/10.5.1.1/derby-10.5.1.1.pom
>>>>>>>>>>>
>>>>>>>>>>> @Ethan: is the reference in the pom.xml file
correct?
>>>>>>>>>>>
>>>>>>>>>>> D.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Dec 6, 2009 at 6:29 PM, Ethan Jewett
<esjewett@gmail.com> wrote:
>>>>>>>>>>>> BTW, in case anyone is interested, I used
this blog as my jumping-off
>>>>>>>>>>>> point into Derby and H2 documentation:
>>>>>>>>>>>> http://agoncal.wordpress.com/2009/07/05/derby-10-5-1-1-is-really-an-in-memory-database/
>>>>>>>>>>>>
>>>>>>>>>>>> Ethan
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Dec 6, 2009 at 11:27 AM, Ethan Jewett
<esjewett@gmail.com> wrote:
>>>>>>>>>>>>> I've posted a patch to issue 142
>>>>>>>>>>>>> (https://issues.apache.org/jira/browse/ESME-142).
 The patch upgrades
>>>>>>>>>>>>> the version of Derby we are using in
pom.xml and switches the test
>>>>>>>>>>>>> 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 <hirsch.dick@gmail.com> wrote:
>>>>>>>>>>>>>> @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 to
>>>>>>>>>>>>>> allow in-memory usage. I looked but
didn't find anything.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 4, 2009 at 7:52 PM, Ethan
Jewett <esjewett@gmail.com> wrote:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> <feeder.of.the.bears@gmail.com>
wrote:
>>>>>>>>>>>>>>>> On Fri, Dec 4, 2009 at 9:32
AM, Ethan Jewett <esjewett@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message