Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of
 lists+1214986235816-210739@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1242858699222-2949105.post@n2.nabble.com>
Date: Wed, 20 May 2009 15:31:39 -0700 (PDT)
From: Pinaki Poddar <ppoddar@apache.org>
To: dev@openjpa.apache.org
Subject: Re: [DISCUSS] Propose additional uses for openjpa-integration
In-Reply-To: <4A12E81E.2000205@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4A12E81E.2000205@apache.org>


Hi Donald,
  If primary motivation for this proposal is to speed up the test execution
-- I support that. But I do not like the idea of splitting test corpus in
smaller buckets to achieve that goal or reflecting this goal on project
module structure. 
 There is a need for sure to be able to run a subset of tests while a
development is focused on a relatively isolated aspect. But I have seen it
many a times that a rather innocuous change in one part of the software
propagates in its impact to an apparently unrelated segment (and this
behavior is generic to *any* discreet system, not only to OpenJPA). That is
the downside risk if we promote test corpus to be spread/split.

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


-----
Pinaki Poddar                      http://ppoddar.blogspot.com/
                                      
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
-- 
View this message in context: http://n2.nabble.com/-DISCUSS--Propose-additional-uses-for-openjpa-integration-tp2940913p2949105.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.