[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink ...
|
JPA is definitely our priority and what we will be recommending customers adopt. I agree that this should be the focus of testing for new functionality and EclipseLink specific extensions to JPA.
That being said we will have customers who like our native API or will use our native API in conjunction with JPA where needed. We need to continue to ensure there are no regressions in this functionality.
Doug
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of James
Sutherland
Sent: Thursday, October 04, 2007 9:16 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink
...
One thing we should think about in adding support for adding new JUnit4 test support to the core / POJO tests is whether we should be adding any new POJO tests in general. We desire all new users to use our JPA API and do not anticipate new users using our POJO API, so it baffles me why we would be adding tests for new functionality through the POJO API instead of the JPA API.
New tests for the POJO API should be limited to tests for bug fixes from users using the POJO. All new functionality should be tested through JPA.
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of David Twelves
Sent: Wednesday, October 03, 2007 4:33 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink ...
Minutes: Discussion on including JUnit4 extension for TopLink DBWS in
EclipseLink testing framework.
Date: Wed, Oct 3
Attendees: David Twelves, Mike Norman, Peter Krogh, Gordon Yorke, Tom Ware.
Minutes:
Why is this extension required?
This JUnit4 custom extension was originally developed to provide the ability
to extract platform and database credentials from the testing framework and
ensure that these are available at runtime. The EclipseLink DBWS component
and the related foundation feature, support for non-JDBC PL/SQL types, both
have a requirement for this functionality. Currently, ~200 tests across
these two components are reliant on this JUnit extension.
Issues with introducing this extension that will need addressing.
1. Our overall test strategy for EclipseLink is still under development.
Inclusion of this JUnit4 extension is definitely a possibility, but that
decision should be deferred until the overall strategy is confirmed.
2. Inclusion of this extension would result in another properties files that
would need to be supported, if this custom runner were chosen to execute a
test suite.
3. If we adopt this extension and have this common functionality used
throughout EclipseLink for testing, our upgrade strategy to JUnit5 would
need to be considered in the future. It is unknown how much extra work this
would entail at this time.
4. This extension was originally developed for use within the Oracle 11gR1
test environment. Other solutions may be more readily available in an
EclipseLink environment, reducing the necessity for inclusion of this
extension.
Action items:
1. Mike N to start a Wiki page aimed at capturing all test requirements from
different components that will be fed into the planning stage for the
overall EclipseLink test strategy.
2. Mike N to back the JUnit custom extension out of the EclipseLink SVN
repository for now, until that test strategy is complete and we can
determine whether the extension is required in this environment or not.
Regards,
David Twelves
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of David Twelves
Sent: October 2, 2007 3:53 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink
...
Hi there,
I suggest we have a meeting to review this proposal and determine how this
testing infrastructure should be best incorporated into EclipseLink and the
process steps required to make that happen.
Suggested attendees: David, Mike, Peter, Gordon, Tom
Date: Wed 3rd Oct
Time: 10am EST
Ottawa location: 4048 dev meeting room
Dial in information:-
1888 967 2253
Meeting ID: 702092
Password: 702092
Original design document attached.
Thanks,
David
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Michael Norman
Sent: October 2, 2007 1:43 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink ...
A quick perusal of some other Eclipse projects show that their top-level
folders rarely have
anything to do with bugzilla components. Now this is either because those
project-owners
didn't set out to make it work out that way, or inevitably the mis-match
between CVS/SVN directory
structures, Eclipse projects and bugzilla leads you away from this idea ...
time will tell.
I still think now would be the best time to introduce a 'commons' folder,
but obviously I'm
on the losing end of this vote.
so ... moving stuff into core:
- check-in ant.jar into eclipselink.core.lib (OK according to CQ 1768)
- check-in the source to the pb4 JUnit4 runner into eclipselink.core.test
(OK according to CQ 1755)
+1 from me ;-)
Doug Clarke wrote:
>
> Mike,
>
> At present our top level folders equate to our components and thus to
> bugzilla components. I would like to see us keep this structure. Without
> this the community cannot easily file a bug against our work in this
> project in an obvious fashion.
>
> If there is unanimous agreement that there is a quantity of code that does
> not fall within foundation but is worth keeping in a common component
> outside then we can discuss as a group and work through the new component
> process.
>
> I expect that DBWS in general has a dependency on foundation and therefore
> could leverage any infrastructure stored in foundation's
> eclipselink.core.test or eclipselink.extension.oracle.test.
>
> Doug
> -----Original Message-----
> From: Mike Norman [mailto:michael.norman@xxxxxxxxxx]
> Sent: Tuesday, October 02, 2007 11:21 AM
> To: Peter Krogh; Twelves David; Tom Ware; Gordon Yorke; Doug Clarke
> Cc: Dev mailing list for Eclipse Persistence Services
> Subject: Re: [eclipselink-dev] Using JUnit4 and Ant in EclipseLink ...
>
>
> First off, because of Oracle's wonderful e-mail system (in combination
> with whatever is at the other
> end of eclipselink-dev), I didn't see Tom's e-mail this morning. I was
> under the impression, based on
> our face-2-face discussions yesterday afternoon that 'commons' was a GO
> - obviously not.
>
> I still strongly believe that we should have a 'commons'
> directory-structure (and parallel Eclipse projects).
> The first example of common library and/or code is the custom JUnit4
> runner for testing, hence the
> sub-dir "eclipselink.commons.testing":
>
> ${eclipselink-svn-directory-root}
> \---trunk
> | about.txt
> | ...
> |
> +---commons
> | \---eclipselink.commons.testing
> | | .classpath
> | | .project
> | | pb4.jardesc
> | |
> | +---lib
> | | about.txt
> | | ant.jar
> | | junit4-ext-pb4.jar
>
>
> It is used by both DBWS tests and non-JDBC args tests. Second, some DBWS
> tests do not depend on core
> EclipseLink at all - just a JDBC connection from which metadata is
> extracted (unit testing what happens in the
> DBWS BuildDBWSWar Ant task)
>
> re: Gordon's comments about testing frameworks
> I would like to clarify - there are only 2 testing frameworks, our
> internal one and JUnit4.
> The custom JUnit4 runner I wrote is not a third framework - it is more
> like a 'helper'
> in the same way that XMLUnit was a 'helper' to JUnit3.
>
>
--
View this message in context:
http://www.nabble.com/Using-JUnit4-and-Ant-in-EclipseLink-...-tf4549746.html
#a13003700
Sent from the EclipseLink - Dev mailing list archive at Nabble.com.
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev << File:
TopLink11_14737_DS_nonJDBC_dataTypes - 2007-08-21.pdf >> << File:
ATT01799.txt >>
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
