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
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 vdic...@apache.org wrote:
Looks like you configured not only the test DB, but also the main
It's already changed :) The old DB should still be good to use if it
wasn't explicitly cleaned up.
On Thu, Dec 10, 2009 at 2:02 PM, Richard Hirsch hirsch.d...@gmail.com wrote:
oops.
Thanks. That wasn't intended but it is good to know that the option exists.
Can you please change it back and
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.d...@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
just set clean compile to the maven options
On Mon, Dec 7, 2009 at 5:05 PM, Ethan Jewett esjew...@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.d...@gmail.com wrote:
The build is now working successfully - with
@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 esjew...@gmail.com wrote:
Would
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
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 esjew...@gmail.com wrote:
I've posted a patch
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
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
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.d...@gmail.com wrote:
Trying to figure what the problem is...
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
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
Just wanted to add that I've had this problem in the past when I was
trying to run on Java 5. Since some of the derby class files were
built with a higher version number, they wouldn't be loaded, so
loading the derby driver would fail.
This doesn't really answer the question, though, because I
I'm up to date on the latest revision and it seems to be working fine,
at least as far as the tests are concerned.
Ethan
On Thu, Dec 3, 2009 at 5:01 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Fixes are up in the repo
On Thu, Dec 3, 2009 at 2:15 PM, David Pollak
On Fri, Dec 4, 2009 at 5:35 AM, Ethan Jewett esjew...@gmail.com wrote:
I'm up to date on the latest revision and it seems to be working fine,
at least as far as the tests are concerned.
Ethan,
You have code that is not part of the repo. Please make sure you add
import net.liftweb.common._
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
fairly well killed off :-)
It's working fine at the moment for me.
On Fri, Dec 4, 2009 at 9:32 AM, Ethan Jewett esjew...@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
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.be...@gmail.com wrote:
On Fri, Dec 4, 2009 at 9:32 AM, Ethan Jewett esjew...@gmail.com wrote:
I'm not following.
My local repo exactly matched the trunk
Hi all,
Currently tests are failing to run for me with a mvn clean test in
the trunk server on the latest revision (886861). Can someone confirm?
We can then identify what check-in broke the build and fix it.
Failure is below, which seems to match the failure occurring in Hudson.
Thanks,
Ethan
I'll try to reproduce and fix.
On Thu, Dec 3, 2009 at 9:49 AM, Ethan Jewett esjew...@gmail.com wrote:
Hi all,
Currently tests are failing to run for me with a mvn clean test in
the trunk server on the latest revision (886861). Can someone confirm?
We can then identify what check-in broke
I had the same problem yesterday. Don't know where it came from -
since I didn't change the test files. I agree with Ethan that it is
the same problem in Hudson. I'd like to get it solved, because then we
can follow the tests in a clean environment that Hudson represents.
D.
On Thu, Dec 3, 2009
Sorry. I just checked the last Hudosn build ( ) and the exception is
different. It is the one we've had for a while.
org.apache.maven.surefire.booter.SurefireExecutionException: null;
nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at
Here is the URL to the console output from the last Hudson build -
http://hudson.zones.apache.org/hudson/job/ESME/30/console -- you'll
notice that the error is different from Ethan's initial exception .
D.
On Thu, Dec 3, 2009 at 8:21 PM, Richard Hirsch hirsch.d...@gmail.com wrote:
Sorry. I just
I just built with an anonymous user on a machine with no Postgres or
anything else. mvn clean test install worked like a charm. Are you
running another Maven command?
On Thu, Dec 3, 2009 at 11:21 AM, Richard Hirsch hirsch.d...@gmail.comwrote:
Sorry. I just checked the last Hudosn build ( )
Fixes are up in the repo
On Thu, Dec 3, 2009 at 2:15 PM, David Pollak
feeder.of.the.be...@gmail.comwrote:
Okay,
I reproduced the issue (I guess for some reason my git svn version of ESME
is not up to date... sigh).
The issue is exactly as the error indicates. The particular line
26 matches
Mail list logo
