Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


-----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
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
> 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:
Sent from the EclipseLink - Dev mailing list archive at

eclipselink-dev mailing list

Attachment: TopLink11_14737_DS_nonJDBC_dataTypes - 2007-08-21.pdf
Description: Adobe PDF document

Back to the top