On Mar 6, 2007, at 9:42 PM, Patrick Linskey wrote:

Which class should we use as the real base class?

Hmm. SingleEMTest does have a lot more functionality, but one downside
of it is that it obfuscates our test cases a bit, making them less
useful as examples of JPA code usage.

Obfuscation should be eschewed.

Which project does it belong in?

Sadly, in maven, there is no way (that I know of) for one module to
extend test classes defined in a different module.

IIRC, you can declare binary dependencies for test as well as src code. True, you cannot have sources in two different modules but we're just looking for a binary dependency, right?

OOTH, some of the things I'd like to see in the base class for persistence are EMF and EM, so they don't really belong too far upstream.

Additionally, when
run, tests do not include the contexts of downstream modules. These two facts mean that any end-to-end test must be in openjpa-persistence- jdbc
or somewhere downstream of it, and that the base class for end-to-end
tests must be in the same module, even though it's not JDBC-specific.

I can see a case for moving the tests in openjpa-persistence-jdbc to
openjpa-jdbc-tests or something like that, but we sadly can't move the
base class up to openjpa-persistence, even though it seems like it
belongs there.

We can try to declare the base test case in e.g. kernel and declare a binary dependency in persistence-jdbc.

I'll ping the maven team and see if I can get some clarity there.

Craig

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this
by email and then delete it.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 7:55 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: org.apache.openjpa.persistence.test.PersistenceTestCase

There's a bunch of stuff that we use in the JDO base test
class. I'll
take a look and see what might be useful for us here.

Which class should we use as the real base class? Which project does
it belong in?

Craig

On Mar 6, 2007, at 7:50 PM, Marc Prud'hommeaux wrote:

Patrick-

FYI, I had also put some of that sort of logic in the
org.apache.openjpa.persistence.test.SingleEMTest base test case.

We might want to consider merging duplicate functionality at some
point.



On Mar 6, 2007, at 6:09 PM, Patrick Linskey wrote:

Hi,

In implementing a new test case for OPENJPA-121, I decided to stop
copying-and-pasting the setUp() from other test cases, and instead
create a new PersistenceTestCase base class.

Based on our experience over the last few years, there are
a bunch of
things that would be useful in such a class. I decided to just
start off
with what I needed for my particular test case, though. As we move
forward, if you run across functionality that you think
would make
sense
in a base test case class, please consider putting it into that
class.
One example might be a means to automatically delete all
instances of
the types used by the test case during setUp() and tearDown().

-Patrick

--
Patrick Linskey
BEA Systems, Inc.


_____________________________________________________________________
__
Notice:  This email message, together with any attachments, may
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
entities,  that may be confidential,  proprietary,  copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please
immediately return
this
by email and then delete it.


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to