I don't think we'll need them anymore, but didn't get around to removing
them yet. I guess I wanted to wait to make sure Derby in-memory
(http://db.apache.org/derby/docs/10.7/devguide/cdevdvlpinmemdb.html)
works for everyone.
I wish I had a Mac so I could test the problem here, see what the matter
is. I'm trying to Google, not much.
Eventually we may switch anyway to HSQLDB which is also in-memory and
can hopefully work for everyone.
Glen
On 07/14/2013 06:21 PM, Dave wrote:
Also, if we are using "memory" for Derby do we still need the Ant tasks
that start and stop Derby.
If we don't need them, that seems like a big win.
- Dave
On Sun, Jul 14, 2013 at 6:16 PM, Dave <[email protected]> wrote:
I'm going to look at setting up things so that we only use "memory" when
NOT running on Mac OS.
- Dave
On Sun, Jul 14, 2013 at 6:14 PM, Glen Mazza <[email protected]> wrote:
The single test that's failing I can look at (if you can't immediately
spot the error due to your greater knowledge of the code), since I can
replicate it. But the "memory" portion should be working OOTB for you,
everything good (except that test) with a simple "mvn clean test".
In-memory Derby is *fast*, so it would be very nice to keep it if we can.
Glen
On 07/14/2013 06:04 PM, Dave wrote:
Hey Matt,
Are you able to run "mvn clean test" on Roller trunk on your Mac? Does it
work?
- Dave
On Sun, Jul 14, 2013 at 5:37 PM, Glen Mazza <[email protected]>
wrote:
Hi Dave, tests run fine from my Ubuntu desktop but when I did a fresh
checkout of roller-trunk and ran from my Ubuntu laptop, I got your
second
result ("memory" works fine but I got the same UserTest error), it
happened
both times I tried it. When I ran from my laptop that test alone, i.e.,
"mvn test -Dtest=UserTest", *then* it worked fine (all three times I ran
it).
I'm not sure what the problem is -- it might be related to EclipseLink,
I
learned earlier the EclipseLink (as well as Hibernate) requires explicit
commits in some cases where OpenJPA doesn't:
https://github.com/gmazza/**
blog-samples/blob/master/jpa_****and_junit/src/main/java/**
SampleRun.java#L44<https://**github.com/gmazza/blog-**
samples/blob/master/jpa_and_**junit/src/main/java/SampleRun.**java#L44<https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/java/SampleRun.java#L44>
.
That, or maybe the tests aren't fully independent of each other (one's
requiring another to have run first, I don't know.)
Glen
On 07/14/2013 04:49 PM, Glen Mazza wrote:
That won't do..."memory" refers to Derby's in-memory database,
something
I put in to reduce the build time about 25% (instead of needing to
manually
create files, etc.)...
I just use "mvn clean install", I don't have any problem on my machine
with it...
Glen
On 07/14/2013 04:21 PM, Dave wrote:
If I remove the string "memory:" from the two Roller property files in
test/src/resources then do not get that error and all test pass except
for
the following:
Results :
Failed tests:
testUserLookups(org.apache.****roller.weblogger.business.****
UserTest):
expected:<[userTest]User> but was:<[admin]User>
testRoleCRUD(org.apache.****roller.weblogger.business.****
UserTest):
expected:<2>
but was:<1>
Tests run: 130, Failures: 2, Errors: 0, Skipped: 0
Still digging...
- Dave
On Sun, Jul 14, 2013 at 4:11 PM, Dave <[email protected]> wrote:
I'm going to investigate now, but just in case anybody else knows
what's
up...
--- ROOT CAUSE ---
java.sql.****SQLNonTransientConnectionExcep****tion: The connection
was
refused
because the database memory:rollerdb was not found.
at
org.apache.derby.client.am.****SQLExceptionFactory40.****
getSQLException(Unknown
Source)
at org.apache.derby.client.am.****SqlException.getSQLException(***
*Unknown
Source)
at org.apache.derby.jdbc.****ClientDriver.connect(Unknown Source)
Thanks,
Dave
