Return-Path: 
 <jdo-dev-return-77-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org>
Delivered-To: apmail-db-jdo-dev-archive@www.apache.org
Received: (qmail 28641 invoked from network); 21 Feb 2005 16:46:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 21 Feb 2005 16:46:02 -0000
Received: (qmail 55264 invoked by uid 500); 21 Feb 2005 16:46:02 -0000
Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jdo-dev-help@db.apache.org>
List-Unsubscribe: <mailto:jdo-dev-unsubscribe@db.apache.org>
List-Post: <mailto:jdo-dev@db.apache.org>
List-Id: <jdo-dev.db.apache.org>
Reply-To: jdo-dev@db.apache.org
Delivered-To: mailing list jdo-dev@db.apache.org
Received: (qmail 55250 invoked by uid 99); 21 Feb 2005 16:46:01 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from mail.spree.de (HELO miraculix.spree.de) (62.154.194.149)
  by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 21 Feb 2005 08:46:00 -0800
Received: from [127.0.0.1] (merlin.spree.de [172.16.1.107])
	by miraculix.spree.de (8.11.6/8.11.6) with ESMTP id j1LGjsO22767
	for <jdo-dev@db.apache.org>; Mon, 21 Feb 2005 17:45:54 +0100
Message-ID: <421A1042.6070601@spree.de>
Date: Mon, 21 Feb 2005 17:45:54 +0100
From: Michael Bouschen <mbo.tech@spree.de>
Organization: Tech@Spree Engineering
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jdo-dev@db.apache.org
Subject: Re: Steps to running the TCK against jpox & derby
References: <421653E4.7070802@sun.com>
In-Reply-To: <421653E4.7070802@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hi Michelle,

please find two comments below.

> Hi, Michael and others,
> 
> Here's what I've done to get jpox and derby to run against the TCK, to 
> the point where they need to find tables in the database.
> 
> 1. Put jpox-1.1.0-beta-1.jar in tck11/iut_jars.
> 2. Put log4j-1.2.9.jar in tck11/iut_jars. (jpox needed this.)
> 3 Edit tck11/project.properties:
> # iut
> iut.properties = ${basedir}/jpox.properties
> 4. Create jpox.properties:
> javax.jdo.PersistenceManagerFactoryClass=org.jpox.PersistenceManagerFactoryImpl 
> 
> #javax.jdo.PersistenceManagerFactoryClass=org.apache.jdo.impl.fostore.FOStorePMF 
> 
> org.apache.jdo.ConnectionCreate=true
> javax.jdo.option.ConnectionDriverName=org.apache.derby.jdbc.EmbeddedDriver
> javax.jdo.option.ConnectionURL=jdbc:derby:jdotckdb
> #javax.jdo.option.ConnectionURL=fostore:database/fostore
> javax.jdo.option.ConnectionUserName=tckuser
> javax.jdo.option.ConnectionPassword=tckuser
> javax.jdo.option.Optimistic=false
> javax.jdo.option.RetainValues=false
> javax.jdo.option.RestoreValues=false
> 5. In the classpath section of tck11/maven.xml, place these lines BEFORE 
> the JDO jar file lines:
>        <!-- Jar files for the implementation to be tested -->
>        <path refid="test_iut_jars" />
> else  [java] 1) 
> testGetObjectId(org.apache.jdo.tck.api.jdohelper.GetObjectId)javax.jdo.JDOFatalUserException: 
> JDO 2.0 capabilities cannot be accessed! Please make sure that you do 
> not have a JDO 1.0 jar in front of the JDO 2 classes in your CLASSPATH.
>    [java]      at 
> org.jpox.AbstractPersistenceManagerFactory.<init>(AbstractPersistenceManagerFactory.java:113) 

I hope this issue is gone as soon as we have a api20 subproject that 
creates a jar with the JDO 2.0 API. I think a JDO implementation has to 
pass the TCK using the official JDO API jar. But this is a special 
situation because you run a JDO 2.0 preview implementation against the 
1.1 TCK.

> 
> 6. Manually create a derby database.  I'm using iut_jars as the derby 
> system directory, meaning that it looks there for databases and 
> derby.properties. I wrote some scripts to create the db.  The procedure 
> for deleting a derby database is an OS delete operation on the directory 
> and files.
> 7. Add the following line to maven.xml in the <goal name="runtck.single" 
> ...> section:
>            <sysproperty key="derby.system.home" 
> value="${basedir}/iut_jars"/>

This is a good catch! We need a way to allow IUT specific system 
properties to be set when running the tck. I propose the following solution:
- Add the following line to the file project.properties:
iut.sysproperties = -Dderby.system.home=${basedir}/iut_jars"
A good place is after the definition of the property iut.properties.
- Add the following line to the goals runtck.single and runtck:
<jvmarg line="${iut.sysproperties}"/>
It replaces the new sysproperty setting. This allow specifying one or 
more system properties in project.properties w/o changing the maven.xml. 
What do you think?

Regards Michael

> 
> -- Michelle
> 


-- 
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