openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: Why is slice module not depended on persistence-jdbc module
Date Mon, 22 Jun 2009 15:05:23 GMT
I suspect that one of Pinaki's design goals with Slice was to make it
persistence personality agnostic. So one could use it with a JDO personality
as well as a JPA personality (KODO provides both, OpenJPA provides the

Slice uses both openjpa-persistence and openjpa-persistence-jdbc for testing
though (since no other personalities are available). I imagine if we beefed
up the xml module or added a new personality it would be fairly easy for
Slice to test with them as well.


On Mon, Jun 22, 2009 at 7:13 AM, Donald Woods <> wrote:

> For runtime, Slice only needs access to the jdbc, kernel, and lib jars as
> it is a BrokerFactory/JDBCProvider.  It provides its own ProductDerivation
> in -
>   src/main/java/org/apache/openjpa/slice/
> For junit tests, it should only need to include openjpa-persistence for the
> tests.  If other tests are being added that need to use
> openjpa-persistence-jdbc, then you should ask Pinaki to review your proposed
> tests.
> -Donald
> ashish paliwal wrote:
>> Hi,
>> I wanted to know that why is slice module not depended on
>> openjpa-persistence-jdbc module. I was trying to figure out the reason but
>> could not get to anything conclusive. I felt that both persistence and
>> persistence-jdbc module are central to design of openjpa and since there
>> is
>> dependency on persistence module why is there no dependency on
>> persistence-jdbc module.
>> I actually created a test case in slice module and that test case depended
>> on whether JDBCProductDerivation gets loaded or not. Since, slice module
>> has
>> no dependency on persistence-jdbc moule, it doesn't gets loaded. If I move
>> my test case to example module(which has dependency on persistence-jdbc)
>> then test runs fine.
>> It will be really helpful for me if someone can throw some kight on this.
>> thanks and regards

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message