openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: [DISCUSS] Propose additional uses for openjpa-integration
Date Tue, 19 May 2009 17:48:56 GMT
Good ideas! While we're working on something we might not run top down
builds - instead just test the module that we're interested in. This will
save us all some time unless we have cross module changes (in which case we
might want to do top down builds).

I think that the general pre-commit expectation remains to have done a
complete top-down build though.

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. Optional functions would be better served in the integration bucket.

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

+0.5 I'm not sure the additional Locking testcases are really optional or
integration related. I see some benefit in not running them if you're doing
a lot of builds - I just don't want to see it get excluded entirely.

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.
> 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.

I like this option the best, actually. Much better than putting DB2 / Oracle
specific tests in the openjpa-persistence-jdbc bucket.

> -Donald


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