incubator-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 Mon, 07 Dec 2009 16:55:47 GMT
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