| 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 
  First off, because of Oracle's 
  wonderful e-mail system (in combination with whatever is at the 
  otherend 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.
 
 
 
 --   Mike Norman 
  | Principal Software Designer | 613.288.4638 Oracle Server Technologies | 
  TopLink Product
 45 O'Connor Street, Suite 400 | Ottawa, ON K1P 1A4 | (fax) 
  613.238.2818
 
 
 |