TestRunner status
TestRunner is a project to automate running the TCK for all databases,
identity types, security settings, schemas, mappings, and test cases
with a single maven invocation. We discussed doing the hard stuff
either in maven or with an extended java/JUnit TestRunner. It seems
possible to do it in maven. Below is a working outline of a maven goal
that loops through the various parameters and repeatedly executes a test
run, followed by the results generated by this goal.
___
maven.xml:
___
...
${jdo.tck.dblist}
${jdo.tck.idlist}
file="${basedir}/test/conf/configurations.list"/>
${jdo.tck.cfglist}
file="${basedir}/test/conf/${jdo.tck.cfg}"/>
Install schema in ${jdo.tck.db}
Enhance classes for ${jdo.tck.id}
Run tck using database ${jdo.tck.db},
identity type ${jdo.tck.id},
configuration ${jdo.tck.cfg}
Run test classes ${jdo.tck.classes}
with test data ${jdo.tck.testdata}
and mapping/schema files ${jdo.tck.mapping}
___
Results:
___
$ maven -o runallcfgs.jdori
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
You are working offline so the build will continue, but
jpox-SNAPSHOT.jar may be out of date!
You are working offline so the build will continue, but
jdo2-api-SNAPSHOT.jar may be out of date!
You are working offline so the build will continue, but
jpox-enhancer-SNAPSHOT.jar may be out of date!
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to c:\svn5\jdo\trunk\tck20/target/classes
testrunner.set:
copyprops:
runallcfgs.jdori:
databaseStub:
[echo] Install schema in derby
databaseStub:
[echo] Install schema in mysql
databaseStub:
[echo] Install schema in oracle
enhanceStub:
[echo] Enhance classes for application
enhanceStub:
[echo] Enhance classes for datastore
runtckStub:
[echo] Run tck using database derby,
identity type application,
configuration cfg1.conf
[echo] Run test classes
org.apache.jdo.tck.api.jdohelper.GetObjectIdForNull
org.apache.jdo.tck.api.jdohelper.GetObjectIdForTransient
org.apache.jdo.tck.api.jdohelper.GetObjectIdNotPersistenceCapable
org.apache.jdo.tck.api.jdohelper.GetPersistenceManager
org.apache.jdo.tck.api.jdohelper.GetPersistenceManagerForNull
org.apache.jdo.tck.api.jdohelper.GetPersistenceManagerForTransient
org.apache.jdo.tck.api.jdohelper.GetPersistenceManagerNotPersistenceCapable
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectId
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectIdForNull
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectIdForTransient
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectIdNotPersistenceCapable
with test data
and mapping/schema files
runtckStub:
[echo] Run tck using database derby,
identity type application,
configuration cfg2.conf
[echo] Run test classes
org.apache.jdo.tck.mapping.CompanyModelCompletenessTest
with test data org.apache.jdo.tck.pc.company.company.xml
and mapping/schema files
org.apache.jdo.tck.pc.company.company.orm
runtckStub:
[echo] Run tck using database derby,
identity type application,
configuration cfg3.conf
[echo] Run test classes
org.apache.jdo.tck.mapping.CompanyModelCompletenessTest
with test data org.apache.jdo.tck.pc.company.company2.xml
and mapping/schema files
org.apache.jdo.tck.pc.company.company2.orm
runtckStub:
[echo] Run tck using database derby,
identity type datastore,
configuration cfg1.conf
[echo] Run test classes
org.apache.jdo.tck.api.jdohelper.GetObjectIdForNull
org.apache.jdo.tck.api.jdohelper.GetObjectIdForTransient
org.apache.jdo.tck.api.jdohelper.GetObjectIdNotPersistenceCapab
le org.apache.jdo.tck.api.jdohelper.GetPersistenceManager
org.apache.jdo.tck.api.jdohelper.GetPersistenceManagerForNull
org.apache.jdo.tck.api.jdohelper.GetPersistenceManagerForTransient
org.apache.jd
o.tck.api.jdohelper.GetPersistenceManagerNotPersistenceCapable
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectId
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectIdForNull
org.apache.jdo
.tck.api.jdohelper.GetTransactionalObjectIdForTransient
org.apache.jdo.tck.api.jdohelper.GetTransactionalObjectIdNotPersistenceCapable
Re: JDO TCK Conference Call Friday, May 20, 9 am PST
Attendees: Michelle Caisse, Michael Bouschen, Martin Zaun, Craig Russell Agenda: 1. Test status (Michelle) 4 types of errors that cause most of the problems. Cleanup problem JDO-48, others might be JPOX issues. Forwarded to jdo-dev alias. AI: JPOX developers please respond to email. Michelle fixed a test case bug that now due to cleanup issues causes more tests to fail. One step forward, 30 steps back. Oh well. 2. Test cleanup fix (Michael W.) JDO-48 Michael W sent proposal and looks perfect according to Michelle. The fix is in Michael's workspace but we need a bit more review and update some test cases before checking in. 3. What is test/conf/JDOTCKTestCases.list for? (Michael B.) This used to be the default list of test cases. But now, allTests.list includes all test cases. When we have a new TestRunner implementation, this will be removed. AI: Michelle ask the interested experts whether the GUI part is really needed. 4. Detached objects (Matthew) no change. 5. Build dependency on cvs (Geoff) AI: Michael will post the btree mdr .zip sources on the JDO Wiki in case of problems downloading it from Netbeans. And put a note into README.txt. 6. Apache accounts for Matthew and Eric (Craig) Bugged Geir again. AI: Craig will bug him again. 7. XML Schema (Brian T) no change. 8. JDO API release on ibiblio (Brian T) no change. Other issues and status (any and all) 9. How to get automatic notification from JIRA when a new issue is filed? AI: Craig 10. Can test cases rely on JDOHelper for state interrogation of non-binary-compatibility classes? Yes, but the JDOImplHelper class has not implemented the functionality yet. AI: Craig file JIRA bug and fix it. 11. New TestRunner AI: Michelle will provide an update next week. Status of AI's from weeks past: 12. Almost done with re-factoring effort, ready to check in. New packages core20, enhancer20, runtime20, query20, fostore20. Michael will check these into the repository. 13. We need a way to build the JCP distribution. AI: Craig to define the JCP distributions and see if maven can help. [April 15] AI Brian Topping will update the wiki to tell how to access our releases area. [April 15] AI Brian Topping will do the maven goal for creating and uploading the snapshots. He will create a directory parallel to trunk called "releases" and put the snapshots there. [April 15] AI Matthew will create a directory in the tck.api.persistencemanager called detach in which he will have complete freedom to implement the assertions in the detach section of the specification. [April 22] AI Craig will resolve what happens if an application identity field is changed while the object is detached. [April 22] AI Craig will resolve the serialization contract for a Detachable class so that implementations interoperate. [May 13] AI Brian Topping will implement pushing SNAPSHOT builds of the project to ibiblio. [May 13] AI Craig ask Geir where the committer badges are for Matthew, Erik, and Michael Watsek. [May 13] AI Brian Topping will arrange for automated nightly builds. [May 13] AI Martin Zaun will investigate JSR 294 (Java 5) to see impact on enhancer. [May 13] AI Geoff try to get tck20 to run with JDOMax. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
JDO TCK Conference Call Friday, May 27, 9 am PST
Hi, We will have our regular meeting Friday, May 27 at 9 am PST to discuss JDO TCK issues and status. Dial-in numbers are: 866 230-6968 294-0479# International: +1 865 544-7856 Agenda: Test status (Michelle) Test runner issues (Michelle) Test cleanup fix (Michael W) Next issues (Michael W) Detached objects (Matthew) Apache accounts for Matthew and Eric (Craig) XML Schema (Brian T) JDO API release on ibiblio (Brian T) Other issues and status (any and all) -- Michelle
Re: tck test status
Hi Andy, On May 26, 2005, at 8:35 AM, Andy Jefferson wrote: What is this relationship causing the issue ? I'm guessing a Map in Person of . It is a perfectly valid thing for an impl to want to put a PK on any table. It is also a valid thing for an impl to add additional columns where required to allow duplicates etc. Depends on the exact nature of this relation in question. This page http://www.jpox.org/docs/1_1/relationships_1_N_map.html shows what JPOX currently does for Maps. If you can identify which one you have, then maybe Erik or I can remember why there is an ADPT_PK_IDX column being added in this particular situation. PS. Next nightly build (20050527) will *not* need the use of on both ends of a M-N, so you can have a "mapped-by" on one end and on the other end of the M-N as you had before. Thanks for this. It's great that you guys are so responsive to the TCK team's requests. Craig -- Andy JPOX - Java Persistent Objects Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: tck test status
Andy, Yes, this is a different issue. Using the fixed the previous problem I was running into. In the TCK, we are starting with pre-defined schemas and mappings from the classes to the schemas. There are other valid schema/mapping sets, but we can't just let the vendors autogenerate schema to pass because (1) We can't test all the mapping metadata if we do that. (2) Not all implementations will have automatic schema generation. Apparently there is a gap in the spec around specifying the PK for a join table, so this is a tricky case. We have to find some solution to that. -- Michelle Andy Jefferson wrote: I've done that, but then JPOX seems to want a primary key in the join table and supplies it, though there is none in the schema or metadata. [java] [FATAL] tck - Exception during setUp or runtest: javax.jdo.JDODataStoreException: Put request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) [java] at org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462) Michelle, This is a different issue to the one before. You previously had a M-N between Employee and Project - and so adding the to the other end should have fixed that, presumably it did. What is this relationship causing the issue ? I'm guessing a Map in Person of . It is a perfectly valid thing for an impl to want to put a PK on any table. It is also a valid thing for an impl to add additional columns where required to allow duplicates etc. Depends on the exact nature of this relation in question. This page http://www.jpox.org/docs/1_1/relationships_1_N_map.html shows what JPOX currently does for Maps. If you can identify which one you have, then maybe Erik or I can remember why there is an ADPT_PK_IDX column being added in this particular situation. PS. Next nightly build (20050527) will *not* need the use of on both ends of a M-N, so you can have a "mapped-by" on one end and on the other end of the M-N as you had before.
Re: tck test status
Andy, I see that you and Craig had a discussion about the join table pk issue on the jpox forum http://www.jpox.org/servlet/forum/viewthread?thread=1975 -- Michelle Michelle Caisse wrote: Hi, Andy, Andy Jefferson wrote: Do you have an idea of when you might support this? The new metadata tests I'm working on use the company model and this mapping, so I'm wondering if I should bother to temporarily remap them for debugging. sometime in the next month hopefully. Maybe sooner ... Cool. You can just use the workaround of specifying at BOTH ends of the relationship for now. The real problem is that currently JPOX isn't supporting the specification of on just one end of a M-N - it needs it on both I've done that, but then JPOX seems to want a primary key in the join table and supplies it, though there is none in the schema or metadata. [java] [FATAL] tck - Exception during setUp or runtest: EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) [java] NestedThrowables: [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) [java] at org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462) -- Michelle
Re: tck test status
> I've done that, but then JPOX seems to want a primary key in the join > table and supplies it, though there is none in the schema or metadata. > > [java] [FATAL] tck - Exception during setUp or runtest: > EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) > [java] NestedThrowables: > [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI > 'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put > request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE > (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) > [java] at > org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462) Michelle, This is a different issue to the one before. You previously had a M-N between Employee and Project - and so adding the to the other end should have fixed that, presumably it did. What is this relationship causing the issue ? I'm guessing a Map in Person of . It is a perfectly valid thing for an impl to want to put a PK on any table. It is also a valid thing for an impl to add additional columns where required to allow duplicates etc. Depends on the exact nature of this relation in question. This page http://www.jpox.org/docs/1_1/relationships_1_N_map.html shows what JPOX currently does for Maps. If you can identify which one you have, then maybe Erik or I can remember why there is an ADPT_PK_IDX column being added in this particular situation. PS. Next nightly build (20050527) will *not* need the use of on both ends of a M-N, so you can have a "mapped-by" on one end and on the other end of the M-N as you had before. -- Andy JPOX - Java Persistent Objects
Re: Patch for JDO-48
Hi Michael, This is great! I will add it. To be able to edit Wiki pages you just have to register and log in. There's something at the top right of the page that you click, maybe "User Preferences" or something next to that link. After you log in, the page will have an Edit link instead of "Immutable". -- Michelle Michael Watzek wrote: Hi Michelle, what do I have to do to edit that page. I can see the subsection "Cleanup" but it seems I do not have permission to change it.
Re: tck test status
Hi, Andy, Andy Jefferson wrote: Do you have an idea of when you might support this? The new metadata tests I'm working on use the company model and this mapping, so I'm wondering if I should bother to temporarily remap them for debugging. sometime in the next month hopefully. Maybe sooner ... Cool. You can just use the workaround of specifying at BOTH ends of the relationship for now. The real problem is that currently JPOX isn't supporting the specification of on just one end of a M-N - it needs it on both I've done that, but then JPOX seems to want a primary key in the join table and supplies it, though there is none in the schema or metadata. [java] [FATAL] tck - Exception during setUp or runtest: EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) [java] NestedThrowables: [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI 'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?) [java] at org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462) -- Michelle
Re: Patch for JDO-48
Hi Michelle, what do I have to do to edit that page. I can see the subsection "Cleanup" but it seems I do not have permission to change it. Below you find a proposal for "Cleanup" description: The TCK uses the JUnit testing framework. JUnit encourages test classes to separate the real task to be tested from testing environment setup, relatively testing environment cleanup. TCK classes follow this implementation strategy. For this reason, all TCK test classes extend abstract class "org.apache.jdo.tck.JDO_Test". This class provides two hooks that subclasses may override for test environment setup and test environment cleanup: protected void localSetUp() protected void localTearDown() TCK classes usually set up persistent data in method "localSetUp" and they cleanup that that data in method "localTearDown". The real testing tasks are implemented in methods having the prefix "test". Class JDO_Test implements a default strategy for "localTearDown": All persistent data that has been added for tear down is cleaned up automatically. Thus, TCK classes usually do not override "localTearDown". JDO_Test defines three methods adding persistent data for tear down: protected void addTearDownObjectId(Object oid) protected void addTearDownInstance(Object pc) protected void addTearDownClass(Class pcClass) The first two methods may be used to add single persistent instances for tear down. Method "addTearDownInstance" is convenience delegating to addTearDownObjectId. The last method may be used to add persistent classes for tear down. In the latter case, the extents of all added classes are deleted. *Note*: The order of adding tear down instances and classes is significant. The default implementation of "localTearDown" first deletes all added instances in exactly that order they have been added. Afterwards it deletes the extents of all classes in exactly that order they have been added. Regards, Michael Hi, Michael, When you get a chance, could you please add information on how to code cleanup in a test to the TechnologyCompatibilityKit Wiki page http://wiki.apache.org/jdo/TechnologyCompatibilityKit? I added a section called "Test Development Guidlines" and a subsection called "Cleanup". Thanks, Michelle Michael Watzek wrote: Hi, attached you find the patch for JDO-48. ... -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ ---
Re: tck test status
> > Do you have an idea of when you might support this? The new metadata > > tests I'm working on use the company model and this mapping, so I'm > > wondering if I should bother to temporarily remap them for debugging. > sometime in the next month hopefully. Maybe sooner ... You can just use the workaround of specifying at BOTH ends of the relationship for now. The real problem is that currently JPOX isn't supporting the specification of on just one end of a M-N - it needs it on both -- Andy JPOX - Java Persistent Objects
Re: tck test status
> >OK. You'll just have to put it down to "not currently supported by JPOX" > > with that MetaData definition. We support M-N just in a different way. > > Do you have an idea of when you might support this? The new metadata > tests I'm working on use the company model and this mapping, so I'm > wondering if I should bother to temporarily remap them for debugging. Hi Michelle, sometime in the next month hopefully. Maybe sooner ... -- Andy JPOX - Java Persistent Objects
