9 messages in org.apache.openjpa.devRe: [DISCUSS] Propose additional uses...| From | Sent On | Attachments |
|---|---|---|
| Donald Woods | May 19, 2009 10:10 am | |
| Michael Dick | May 19, 2009 10:48 am | |
| Kevin Sutter | May 19, 2009 11:01 am | |
| Jeremy Bauer | May 20, 2009 7:26 am | |
| Miłosz Tylenda | May 20, 2009 10:24 am | |
| Donald Woods | May 20, 2009 1:48 pm | |
| Pinaki Poddar | May 20, 2009 3:31 pm | |
| Michael Dick | May 20, 2009 8:04 pm | |
| Donald Woods | May 21, 2009 5:52 am |
| Subject: | Re: [DISCUSS] Propose additional uses for openjpa-integration | |
|---|---|---|
| From: | Jeremy Bauer (tech...@gmail.com) | |
| Date: | May 20, 2009 7:26:52 am | |
| List: | org.apache.openjpa.dev | |
Donald,
Great ideas. Comments inline.
On Tue, May 19, 2009 at 12:10 PM, Donald Woods <dwo...@apache.org> 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 moment.
-Jeremy
-Donald