Change CTF test suite from JDO to JDOManager

Ralf, as far as I can tell, the only remaining references to JDO (rather than JDOManager) in src/tests are the ones included in JDOCategory, JDOJ2EECategory and TestInstanceFactory. How do you feel about marking this issue as closed, as imho we may not want to touch these framework classes.

You identified exactly that part of code that I intend to touch with this issue

Having said that there are quite some reasons for this refactoring:
1. ATM we test JDO but not JDOManager
2. I want to delete JDO with 1.0 release
3. There are some tests of features (loading multiple jdo-conf, JDOConfFactory) that can only be tested with JDOManager as JDO don't support them.
(e.g. tests/jdo.test1214, tests/jdo.test1781 or bugs/jdo.bug881).

I also intend to improve JDOCategory to allow execution of J2EE tests as part of our current categories and not as it stands right now as a seperate category.

IMO we should finish the whole refactoring of tests (CASTOR-755, CASTOR-943, CASTOR-1052, CASTOR-1096, CASTOR-1164) latest for 1.0 but better for 0.9.

I meant 0.9.9 at my last comment.

Based upon my earlier comment to you on IRC, how feasable is this going to be within a time frame of three weeks ?

Patch with new tests.dtd, tests.xsd and generated source files. Also added a new task 'gen.tests' to build.xml.

Intention is that the new Main class:

• unmarshal tests.xml into the generated classes
• search harness for the category specified at comand line
• unmarshal the configuration of the categories jdo-tag into a JdoConf
• create a default JDOManager with this JdoConf
  (special JDOManager instances can be created by modified clones of JdoConf)
• add the test specified at commandline or all tests of the category to suite
• run tests

Sounds quite simple so far but we'll see the problems that will come

Classes and test application to parse tests.xml with SAX only. Removed dependency on CastorXML.

Just looked at this latest patch. The first thing that grabbed my attention is the fact that the Java classes (representing the various XML elements in a tests.xml file, e.g. Category et alias) are not simple POJOs any more, but include code (and logic) specific to SAX parsing. And I am not sure whether this is a step in the right direction.

Well, there is always more then one way to implement things. We can also seperate parsing code and POJO's but this would about double the classes and I'm not sure if this would make code easier to understand. In addition there are more objects to be created in that case which would make parsing slower even if that is not important in that case. I expect code to be quite similar when seperated into Handler for parsing and POJO if you still prefer that.

In addition will it be required to translate parts of the object tree after unmarshalling into a TestSuite with TestCases that hold all the information contained in tests.xml including the jdo-conf in this case.

Having said that if it wouldn't be tests.xml we are talking about, I would have introduced an intermediat layer with interfaces and POJO's which is independent of marshaller and XML syntax. According to our discussion about mappings on IRC yesterday, I had been think about that for quite some time in the evening. As a compromis I would acept to stay with umarshalling mappings with CastorXML for the time being when using following design:

• create an intermediat layer with interfaces and POJO's that are not generated
• only access these intermediate layer internaly (at minimum in database part but better also in XML part)
• we should take care to allow loading of 2 differnt mappings for the same class (e.g. EJB for database / JAXB for marshalling)
• the class mappings should not be verified at load time but when executing a verify run later when all mappings are loaded
• offer different implementations of mapping loaders e.g.
• loader for castor mappings based on CastorXML
• loader for EJB XML mappings based on CastorXML
• loader for EJB annotation mappings
• loader for JAXB mappings ???
• loader for XML mappings based on SAX2 only ???

While the first 3 are required and should be added step by step are the last 2 optional to be added by those who want them.

I'd like to close this issue as won't fix and start adding a new test framework with castor-1906.

+1.

Closed with resolution won't fix as explained above.