You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2005/12/31 02:50:03 UTC
RunRules for JDO TCK
Javadogs,
Attached please find the first draft of the TCK run rules for JDO
2.0. Please comment.
Craig

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: RunRules for JDO TCK
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
two minor comments:
Please mention that we are using maven 1 (recommended version is maven
1.0.2). We do not run with maven 2.
Section "Running the Tests" describes to use 'maven multiproject:build'
to build the requires jars. This works because the distribution does not
contain all the subprojects from the repository. If you call the same
command in your svn workspace it would build all the JDO1 and JDO2
subprojects. I propose to call 'maven tck20.build' instead. This builds
tck20 including any dependent JDO subprojects and works in both
environments: the distribution and an svn workspace.
Regards Michael
> Javadogs,
>
> Attached please find the first draft of the TCK run rules for JDO 2.0.
> Please comment.
>
> Craig
>
>
> ------------------------------------------------------------------------
>
>
> Running the JDO 2.0 Technology Compatibility Kit
>
> Overview
>
> In order to demonstrate compliance with the Java Data Objects
> specification, an implementation must successfully run all of the TCK
> tests that are not on the “excluded” list.
>
> Maven http://maven.apache.org <http://maven.apache.org/> is the driver
> of the test programs.
>
> Normally, the results should be posted on the JDO supplier's web site
> for examination by the public. The posting includes the output of the
> test run, which consists of multiple log files, configuration
> information, and results. For an example of the required posting, please
> see http://db.apache.org/jdo/tck/final.
>
> Installation
>
> Download the zip file from the distribution at the Java Community
> Process web site http://blah <http://blah/> blah. Unpack the zip file
> into a directory of your choice. In this directory you will find: this
> RunRules.html, some configuration files, and several directories:
>
> *
>
> maven.xml, project.properties, project.xml – the maven definition
> of the project. These files must not be modified.
>
> *
>
> assertions – contains the assertions file identifying the
> assertions tested by the tests. This is for reference.
>
> *
>
> target – this directory contains artifacts of compiling and
> running the tests. It is empty in the distribution.
>
> *
>
> iut_jars – this directory is where the JDO implementation jars are
> installed. It is empty in the distribution. To use the maven
> targets runtck.iut (required for an implementation to prove
> compliance), copy the JDO implementation jar files into this
> directory.
>
> *
>
> test – this directory contains the test configuration files and
> directories:
>
> o
>
> testdata – this directory contains data (represented as .xml
> files) loaded into the datastore for tests. These files must
> not be modified.
>
> o
>
> sql – this directory contains DDL to define the tables used
> in the tests. These files may be modified to suit the JDO
> implementation.
>
> o
>
> jdo – this directory contains .jdo metadata files for the
> persistent classes used in the tests. These files must not
> be modified.
>
> o
>
> orm – this directory contains .orm metadata files to map the
> persistent classes to the sql tables. These files may be
> modified to suit the JDO implementation.
>
> o
>
> java – this directory contains the source code to the TCK
> tests. These files must not be modified.
>
> o
>
> conf – this directory contains the configuration information
> for the test runs. These files must not be modified, except
> to put a successfully challenged test case into the
> trunk/tck20/test/conf/exclude.list. Please see below.
>
> Modifying the Configuration
>
> Sample configuration files are provided for the .orm and sql
> configuration for the mapping. These files may be modified in order to
> suit the JDO implementation under test.
>
> Running the Tests
>
> From the trunk directory, run maven multiproject:build which will build
> the required jar files used in the tests, including the API jar.
>
> From the trunk/tck20 directory, run maven runtck.iut to run the tests.
> This will produce console output plus a directory in the
> trunk/tck20/target/logs directory with the date/time the tests were
> started. This directory contains the output of the tests which is to be
> published.
>
> Publishing the Results of the TCK Tests
>
> With a successful test run, the log directory with the results of the
> tests must be published on a publicly-available web site. The unmodified
> directory is the self-certification of the successful TCK test run.
>
> Challenging the Validity of a Test or Configuration
>
> If any test does not pass on the JDO implementation under test, this may
> be due to an error in the implementation or in the TCK test. If you
> believe that the failure is due to an error in the TCK test, you may
> challenge the test. To do so, send email to: jdo-dev@db.apache.org
> <ma...@db.apache.org> with “CHALLENGE” and the name of the test
> program, e.g. org.apache.jdo.tck.api.persistencemanager.ThreadSafe.java
> and detail the issue in the body of the email.
>
> If the issue is found by the Maintenance Lead to be due to an error in
> the test case, then the test may be put into the
> trunk/tck20/test/conf/exclude.list and it will not be run as part of the
> TCK.
>
> Decisions of the Maintenance Lead may be appealed to the full expert
> group. A vote of the full expert group will be conducted by the
> Maintenance Lead, and a majority of votes cast will decide the issue.
> The Maintenance Lead has one vote, as does each member of the expert
> group at the time of the vote.
>
>
> ------------------------------------------------------------------------
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: RunRules for JDO TCK
Posted by er...@jpox.org.
The installSchema goal is only handling derby database. Should't exist a generic
implementation that connects to any database using a jdbc driver, reads and
fires sql scripts to database B, C or D?
Quoting Michael Bouschen <mb...@spree.de>:
> Hi Craig,
>
> > Javadogs,
> >
> > I'm inclined to agree with Andy that the schema and orm files for each
> > of the databases we know of should be standard and specified as part of
> > the TCK.
>
> I agree.
>
> >
> > There is nothing in the TCK tests that should be different in the orm
> > files from one database to another. There are differences in the schema
> > based on column data types, and these differences can be captured in
> > database-specific .sql files.
>
> AFAIK there is nothing in the current orm files that needs to change for
> a different database or that requires vendor specific extensions.
>
> >
> > The only thing we lack is broader testing on different databases. But
> > for now, I'll be happy to require that the orm files be identical among
> > different databases, and even happier if we can get some folks to create
> > the xxx.sql files for databases other than derby.
>
> I'm wondering what needs to be done to test a JDO implementation against
> a database <db> different from derby:
> - Copy all the orm files to package-<db>.orm. This is necessary because
> the orm files include the database in its name, e.g. package-derby.orm.
> - Create a new subdirectory <db> under trunk/tck20/test/sql and provide
> the corresponding sql files schema*.sql.
>
> More?
>
> Regards Michael
>
>
> >
> > Craig
> >
> > On Dec 31, 2005, at 1:09 AM, Andy Jefferson wrote:
> >
> >> Hi Craig,
> >>
> >>> Attached please find the first draft of the TCK run rules for JDO
> >>> 2.0. Please comment.
> >>
> >>
> >> Why is the "sql" modifiable "to suit the JDO implementation" ?
> >> Why is the "orm" modifiable "to suit the JDO implementation" ?
> >>
> >> Surely the ORM defines the underlying schema, and so the ORM files
> >> provided
> >> with the TCK are totally compatible with the schema provided with the
> >> TCK.
> >> That is the premise we have been using with JPOX whilst developing the
> >> TCK.
> >> Why is it different for other implementations?
> >> Can we have some examples of why it would be necessary ?
> >> Are we talking about JDO implementations that don't support Apache
> >> Derby ? In
> >> that case would it not be better to have any other RDBMS files
> >> generated be
> >> fed back to the TCK project and then have them under central control? We
> >> can't have one JDO implementation hand crafting its own SQL files and ORM
> >> files and saying that it is "compatible" when the ORM they have
> >> generated may
> >> be incorrect with respect to the spec and the schema it should equate
> >> to. e.g
> >>
> >>
> >> Thanks
> >> --
> >> Andy
> >
> >
> > Craig Russell
> >
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> >
> > 408 276-5638 mailto:Craig.Russell@sun.com
> >
> > P.S. A good JDO? O, Gasp!
> >
> >
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Re: RunRules for JDO TCK
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
> Javadogs,
>
> I'm inclined to agree with Andy that the schema and orm files for each
> of the databases we know of should be standard and specified as part of
> the TCK.
I agree.
>
> There is nothing in the TCK tests that should be different in the orm
> files from one database to another. There are differences in the schema
> based on column data types, and these differences can be captured in
> database-specific .sql files.
AFAIK there is nothing in the current orm files that needs to change for
a different database or that requires vendor specific extensions.
>
> The only thing we lack is broader testing on different databases. But
> for now, I'll be happy to require that the orm files be identical among
> different databases, and even happier if we can get some folks to create
> the xxx.sql files for databases other than derby.
I'm wondering what needs to be done to test a JDO implementation against
a database <db> different from derby:
- Copy all the orm files to package-<db>.orm. This is necessary because
the orm files include the database in its name, e.g. package-derby.orm.
- Create a new subdirectory <db> under trunk/tck20/test/sql and provide
the corresponding sql files schema*.sql.
More?
Regards Michael
>
> Craig
>
> On Dec 31, 2005, at 1:09 AM, Andy Jefferson wrote:
>
>> Hi Craig,
>>
>>> Attached please find the first draft of the TCK run rules for JDO
>>> 2.0. Please comment.
>>
>>
>> Why is the "sql" modifiable "to suit the JDO implementation" ?
>> Why is the "orm" modifiable "to suit the JDO implementation" ?
>>
>> Surely the ORM defines the underlying schema, and so the ORM files
>> provided
>> with the TCK are totally compatible with the schema provided with the
>> TCK.
>> That is the premise we have been using with JPOX whilst developing the
>> TCK.
>> Why is it different for other implementations?
>> Can we have some examples of why it would be necessary ?
>> Are we talking about JDO implementations that don't support Apache
>> Derby ? In
>> that case would it not be better to have any other RDBMS files
>> generated be
>> fed back to the TCK project and then have them under central control? We
>> can't have one JDO implementation hand crafting its own SQL files and ORM
>> files and saying that it is "compatible" when the ORM they have
>> generated may
>> be incorrect with respect to the spec and the schema it should equate
>> to. e.g
>>
>>
>> Thanks
>> --
>> Andy
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: RunRules for JDO TCK
Posted by Craig L Russell <Cr...@Sun.COM>.
Javadogs,
I'm inclined to agree with Andy that the schema and orm files for
each of the databases we know of should be standard and specified as
part of the TCK.
There is nothing in the TCK tests that should be different in the orm
files from one database to another. There are differences in the
schema based on column data types, and these differences can be
captured in database-specific .sql files.
The only thing we lack is broader testing on different databases. But
for now, I'll be happy to require that the orm files be identical
among different databases, and even happier if we can get some folks
to create the xxx.sql files for databases other than derby.
Craig
On Dec 31, 2005, at 1:09 AM, Andy Jefferson wrote:
> Hi Craig,
>
>> Attached please find the first draft of the TCK run rules for JDO
>> 2.0. Please comment.
>
> Why is the "sql" modifiable "to suit the JDO implementation" ?
> Why is the "orm" modifiable "to suit the JDO implementation" ?
>
> Surely the ORM defines the underlying schema, and so the ORM files
> provided
> with the TCK are totally compatible with the schema provided with
> the TCK.
> That is the premise we have been using with JPOX whilst developing
> the TCK.
> Why is it different for other implementations?
> Can we have some examples of why it would be necessary ?
> Are we talking about JDO implementations that don't support Apache
> Derby ? In
> that case would it not be better to have any other RDBMS files
> generated be
> fed back to the TCK project and then have them under central
> control? We
> can't have one JDO implementation hand crafting its own SQL files
> and ORM
> files and saying that it is "compatible" when the ORM they have
> generated may
> be incorrect with respect to the spec and the schema it should
> equate to. e.g
>
>
> Thanks
> --
> Andy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: RunRules for JDO TCK
Posted by Andy Jefferson <an...@jpox.org>.
Hi Craig,
> Attached please find the first draft of the TCK run rules for JDO
> 2.0. Please comment.
Why is the "sql" modifiable "to suit the JDO implementation" ?
Why is the "orm" modifiable "to suit the JDO implementation" ?
Surely the ORM defines the underlying schema, and so the ORM files provided
with the TCK are totally compatible with the schema provided with the TCK.
That is the premise we have been using with JPOX whilst developing the TCK.
Why is it different for other implementations?
Can we have some examples of why it would be necessary ?
Are we talking about JDO implementations that don't support Apache Derby ? In
that case would it not be better to have any other RDBMS files generated be
fed back to the TCK project and then have them under central control? We
can't have one JDO implementation hand crafting its own SQL files and ORM
files and saying that it is "compatible" when the ORM they have generated may
be incorrect with respect to the spec and the schema it should equate to. e.g
Thanks
--
Andy