RE: [eclipselink-dev] RE: Using JUnit4 and Ant in EclipseLink ...

["Gordon Yorke" <gordon.yorke@xxxxxxxxxx>]

IPzilla approvals are legal approvals and are not community/technically based.
There has been no review of this code by any other committer.
The package names do not follow Eclipse guidelines.
The code includes almost no javadoc or developer comments.
There has been no testing infrastructure formalization making this code premature.

Bug I guess bringing this up is pointless as the repository changes have already been made without any pause for feedback.

--Gordon

-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Michael Norman
Sent: Tuesday, October 02, 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