openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <>
Subject Re: [DISCUSS] Propose additional uses for openjpa-integration
Date Wed, 20 May 2009 14:27:15 GMT

Great ideas.  Comments inline.

On Tue, May 19, 2009 at 12:10 PM, Donald Woods <> wrote:

> There are two scenarios that I'd like us to consider using the
> openjpa-integration component for testing in trunk -
> 1) Validation - using a new integration subproject to test our optional
> bean validation support against one or more providers.  This will allow us
> to keep the junits in openjpa-persistence-jdbc focused on the default no
> validator scenarios.

+1 A simple mechanism to allow running with multiple validation providers
would be very beneficial.  Not burdening the existing test bucket with
validation is also a good idea.  While most of the tests would not do any
real validation (since there are no validation constraints on the entities),
they would still incur the cost of loading up the validator and making the
validation attempt.  Additional execution time for little benefit: -1.

2) Lock/Timeout testing - moving most of the lockmgr and lock/query timeout
> tests out of openjpa-persistence-jdbc to a new integration subproject to
> reduce the time required to run the main-line tests
> Both of the above subprojects would be setup to always run in the tests
> goal, so top-level builds would still run all of the existing plus new
> junits.
> -1 While it would be really nice to have o-p-j build faster, I think moving
these tests into the integration subproject would make it difficult to
differentiate what should/should not go into that subproject.  IMHO,
execution time should not be a deciding factor when choosing whether to add
something to the integration subproject.

> A future scenario to consider, would be moving DB specific tests (that
> target a single DB like Oracle, DB2, ...) into integration subprojects, so
> every junit that remains in openjpa-persistence-jdbc is always active (not
> excluded in surefire or skipped due to the DBDictionary) and should always
> pass on every supported DB.

+1 I think this is a good idea.  It would also provide a structured means to
add, locate, and run database specific tests.  This is fairly ad-hoc at the


> -Donald

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