You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-commits@db.apache.org by mc...@apache.org on 2008/06/27 20:58:11 UTC
svn commit: r672352 - in /db/jdo: HowToReleaseJDO.html HowToReleaseJDO.txt
trunk/README.html trunk/README.txt
Author: mcaisse
Date: Fri Jun 27 11:58:10 2008
New Revision: 672352
URL: http://svn.apache.org/viewvc?rev=672352&view=rev
Log:
JDO-585 Process for providing post-release notes.
Added:
db/jdo/HowToReleaseJDO.html
- copied, changed from r670020, db/jdo/HowToReleaseJDO.txt
db/jdo/trunk/README.html
- copied, changed from r670020, db/jdo/trunk/README.txt
Removed:
db/jdo/HowToReleaseJDO.txt
db/jdo/trunk/README.txt
Copied: db/jdo/HowToReleaseJDO.html (from r670020, db/jdo/HowToReleaseJDO.txt)
URL: http://svn.apache.org/viewvc/db/jdo/HowToReleaseJDO.html?p2=db/jdo/HowToReleaseJDO.html&p1=db/jdo/HowToReleaseJDO.txt&r1=670020&r2=672352&rev=672352&view=diff
==============================================================================
--- db/jdo/HowToReleaseJDO.txt (original)
+++ db/jdo/HowToReleaseJDO.html Fri Jun 27 11:58:10 2008
@@ -1,168 +1,256 @@
-How to Release an Apache JDO Distribution
-
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>JDO Release Process</TITLE>
+</HEAD>
+<BODY LANG="en-US">
+<UL>
+ <LI><a href="#procoverview">Overview of the process</a></LI>
+ <LI><a href="#procdetail">Detailed process steps</a></LI>
+ <LI><a href="#site">Site updates</a></LI>
+ <LI><a href="#postrelease">Post release modifications and documentation</a></LI>
+</UL>
+<h1>How to Release an Apache JDO Distribution</h1>
+<p>
A distribution of JDO is built from a branch of svn. It is copied into a
release directory, from which it is staged and tested prior to release.
Once released, it is propagated to mirror servers around the world.
-
+</p><p>
The process is performed by a release manager with cooperation from testers
in the community.
-
-Overview of the process:
-
+</p>
+<a name="procoverview"></a>
+<h2>Overview of the process</h2>
+<p>
The community first decides on the name of the release. The format
-of the name is <spec-number>.<major>.<minor>.<update>. The spec-number
-is either 1 for JDO 1 or 2 for JDO 2. The major number might change for
-a new JSR. The minor number would change for a specification revision
-approved by the JCP via specification maintenance review. The update number
+of the name is <i>spec-number</i>.<i>major</i>.<i>minor</i>.
+The spec-number is either 1 for JDO 1 or 2 for JDO 2.
+The major number would change for a specification revision
+approved by the JCP via specification maintenance review. The minor number
can be used for changes that do not need a maintenance review and
-do not change the interfaces. Trailing <update> and <minor> numbers
-with zero values are right trimmed, so there might be a 2.0.0.1 or a 2.0.1
-but not a 2.0.0 or 2.0.1.0.
-
+do not change the interfaces.
+A trailing <i>minor</i> number
+with a zero value is right trimmed, so there might be a 2.0.1 but not a 2.0.0.
+</p><p>
Interim releases prior to final release are identified by a suffix on the
release number. Common suffixes include: -alpha, -beta, -beta2, -rc1, -rc2.
Generally, the suffixes are part of the release plan, and the contents
of each suffix release are agreed by the community. There might be
significant changes in functionality between the suffix releases. Each
suffix release goes through the process documented here.
-
+</p><p>
The release manager makes a branch from the trunk (for a major release) or
from another branch (for a minor release) to create a branch with the
source of the distribution.
-
+</p><p>
The release manager modifies the branch to change dependencies from SNAPSHOT
to projects in the release.
-
+</p><p>
The release manager builds and tests the components of the release and
checks the release build into svn.
-
+</p><p>
The release manager publishes the release on a staging area of the apache
server and calls for the community to test the release.
-
+</p><p>
The community tests the release. If necessary, cycle until all issues are
resolved.
-
+</p><p>
The release manager calls for a vote to release by sending a message to the
community and forwarding the message to the pmc.
-
+</p><p>
The community votes on the release. If necessary, cycle until issues are
resolved.
-
+</p><p>
The release manager notifies the pmc of the successful vote outcome.
Note that a successful vote includes three +1 votes from PMC members.
-
+</p><p>
The release manager distributes the release, which is then copied to mirror
sites worldwide.
-
+</p><p>
The release manager notifies the worldwide community of the availability
of the release.
-
-Detailed process steps:
-
-1. Create a branch from the trunk or from another branch. If you are
-creating a major or spec maintenance release, e.g. 2.0, 2.1,
-create a 2.n branch from the trunk. If creating an bug-fix release,
-e.g. 2.0.1.3, create a branch from the 2.0.1 or 2.0.1.2
-branch and apply updates to it.
-
+</p><p>
+The release manager updates the JDO web sites (http://db.apache.org/jdo/index.html, http://java.sun.com/jdo/).
+</p><p>
+If bugs are found or test challenges are sustained after the release is approved and distributed, the release
+manager creates a new branch to address the bugs found.
+</p>
+<a name="procdetail"></a>
+<h2>Detailed process steps</h2>
+<p>
+<OL>
+ <LI>Create a branch from the trunk and increment the spec or major number.
+For example, create a 2.2 branch from the trunk.
+<pre>
cd jdo
svn copy https://svn.apache.org/repos/asf/db/jdo/trunk \
-https://svn.apache.org/repos/asf/db/jdo/branches/2.0
-
-2. Remove the projects and files that are not being released.
+https://svn.apache.org/repos/asf/db/jdo/branches/2.2
+</pre>
+</LI>
+<LI>Remove the projects and files that are not being released.
+<pre>
pushd branches/2.n
svn rm api11 btree fostore20 query20 runtime20 ri11 tck11 JDO11.MF
svn commit -m "Remove projects and files that are not being released"
+</pre>
+</LI>
+<LI>Update dependencies in projects to be released.
-3. Update dependencies in projects to be released.
-
+<pre>
For each project.xml in the branch:
sed /-SNAPSHOT//gcd
popd
+</pre>
If needed, update the dependency to JPOX in the tck20 project.xml.
If needed, apply patches from the trunk or branches to the new branch.
-
-4. Copy the JNDI implementation jars (providerutil.jar and fscontext.jar)
+</LI>
+<LI>Copy the JNDI implementation jars (providerutil.jar and fscontext.jar)
to the branch lib/ext directory. This is needed to test the tck before
distributing it.
-
+<pre>
cp trunk/lib/ext/* branches/2.n/lib/ext
-
-5. Build the distribution. This creates .gz files and .zip files in the
+</pre>
+</LI>
+<LI>Build the distribution. This creates .gz files and .zip files in the
target/distributions directory of each project. It also creates the .jar
and .pom files. It then copies the release artifacts to the
releases/2.n/dist directory. The dist directory is in a format that
can be copied directly to the apache dist directory for distribution.
+It contains two subdirectories; db contains downloadable artifacts and java-repository contains artifacts that are automatically pulled to maven repositories.
Note: Failure possibly due to insufficient heap space was fixed by setting
the environment variable MAVEN_OPTS="-Xmx1024m -Xms1024m -XX:MaxPermSize=512m"
+<pre>
pushd branches/2.n
maven tck2.default
maven tck2.dist
popd
+</pre>
+</LI>
+<LI>Test the release in the branch.
-6. Test the release in the branch.
-
+<pre>
pushd branches/2.n/tck20
maven installSchema
maven runtck.jdori
popd
+</pre>
Also run RAT on the release: http://code.google.com/p/arat/
-
-7. Sign the artifacts. You must have a gpg key in order to perform this step.
+</LI>
+<LI>Sign the artifacts. You must have a gpg key in order to perform this step.
The sign-directory script is checked into jdo/bin. Edit this script to refer
to your own environment (do not check it in).
-bin/sign-directory releases/2.n/dist/jdo2.<n>-rc<m>
-
-8. Push the artifacts to the staging area on the apache server.
-
-scp -r releases/2.n/dist <username>@people.apache.org:~/public_html
-
-Make sure that all the directories have executable permission:
-
-chmod a+x <dir>
-
-9. Test the release from the staging area. Send an announcement to vote
-on the release to the jdo-dev@db.apache.org alias. The message subject
-line contains [VOTE]. Forward the [VOTE] message
+bin/sign-directory releases/2.n/dist/jdo2.<i>n</i>-rc<i>m</i>
+</LI>
+<LI>Push the artifacts to the staging area on the apache server.
+
+<pre>
+scp -r releases/2.n/dist <i>username</i>@people.apache.org:~/public_html
+</pre>
+
+</LI>
+<LI>
+ssh to people.apache.org and change to the public_html directory.
+Make sure that all the copied directories have executable permission. If not change the permission for each:
+
+<pre>
+chmod a+x <i>dir</i>
+</pre>
+ </LI>
+ <LI>Test the release from the staging area.
+ </LI>
+ <LI>Send an announcement to test the release to the jdo-dev@db.apache.org alias. If problems are found, fix and repeat.</LI>
+ <LI>Send an announcement to vote on the release to the jdo-dev@db.apache.org alias.
+ The message subject line contains [VOTE]. Forward the [VOTE] message
to pmc@db.apache.org. Iterate until you get a successful vote. Mail the
-results of the vote to jdo-dev@db.apache.org, bcc: pmc@db.apache.org, and
+results of the vote to jdo-dev@db.apache.org, bcc: general@db.apache.org, and
include [VOTE] [RESULTS] in the subject line.
-
-10. After testing and voting is complete, push the artifacts to the apache web.
+</LI>
+<LI>After testing and voting is complete, push the artifacts to the apache web.
Mirrors automatically pick up Apache artifacts from /www/www.apache.org/dist.
+<pre>
ssh people.apache.org
cp -r public_html/dist /www/www.apache.org
-
-11. Check the distribution into svn
-
+</pre>
+</LI>
+<LI>Check the distribution into svn
+<pre>
svn add releases/2.n
svn commit "JDO-XXX create release 2.n" releases/2.n
-
-12. Update the JDO web site to point the downloads page to the release.
-In site/xdocs/releases create release-2.n.html. In site/docs/releases create
-release-2.n.cgi. The .cgi file contents are identical to the other .cgi
-files in the release directory; only the file name differs. Edit
-site/xdocs/downloads.xml to link to the new release page .cgi document.
-Set the svn properties svn:eol-style to native and svn:executable to true
-for the .cgi files. Build the site from the site directory:
-
-ant
+</pre>
+</LI>
+<LI>After updating the site (below), announce the release to the Apache community via email to
+announce@general.apache.org
+</OL>
+<a name="site"></a>
+<h2>Site updates</h2>
+<OL>
+<LI>Update the Apache JDO web site to point the downloads page to the release.
+<OL>
+ <LI>In site/xdocs/releases create release-2.n.html.</LI>
+ <LI>In site/docs/releases create release-2.n.cgi. The .cgi file contents are identical to the other .cgi files in the release directory; only the file name differs.</LI>
+ <LI>Edit site/xdocs/downloads.xml to link to the new release page .cgi document.</LI>
+<LI>Build and test as described in the site/HOWTO document. </LI>
+<LI>Add the new files to the subversion repository.
+<pre>
svn add xdocs/releases/release-2.n.html
svn add docs/releases/release-2.n.html
svn add docs/releases/release-2.n.cgi
svn commit
+</pre>
+</LI>
+ <LI>Set the svn properties svn:eol-style to native and svn:executable to true for the .cgi files.</LI>
+</OL>
+</LI>
+<LI>Change the link to RunRules on the <a href="http://db.apache.org/jdo/tck.html">TCK</a> page to link to the RunRules.html file of the latest release.
+</LI>
+<LI>Update the news list on the site home page to announce the new release.
+Build, test, and push as described in HOWTO.
+</LI>
+<LI>Add the javadoc for the release to the site.
+<OL>
+ <LI>Make a new directory under site for the release, e.g. api2.1. Call it <i>docsdir</i>.</LI>
+ <LI>Copy the apidocs directory from the release branch target directory to <i>docsdir</i>.</LI>
+ <LI>Make a zip file of the apidocs tree and put it in <i>docsdir</i>.</LI>
+ <LI>Do svn add on <i>docsdir</i>.</LI>
+ <LI>Edit xdocs/javadoc.xml and add links to the new javadoc.</LI>
+</OL>
+</LI>
+<LI> Follow the instructions in site/HOWTO to push the site changes to the Apache web site.</LI>
+</OL>
+<a name="postrelease"></a>
+<h2>Post release modifications and documentation</h2>
+Follow this procedure if a significant bug is found or if the TCK must be modified because a test challenge is found to be valid.
+<OL>
+ <LI>Create a new branch from the release branch, incrementing the minor number. For example, create a branch named 2.1.1, from the 2.1 branch.
+ </LI><LI>Merge bug fixes or other modifications into the new branch.
+ </LI><LI> In the new branch, modify trunk/README.txt to include a section on bug fixes since the 2.1 release, and to suggest checking out the source from a bug-fix branch to get the fixes listed.
+ </LI><LI> Link to this README in the web interface to svn from the .cgi download page and from http://db.apache.org/jdo/tck.html.
+</LI>
+</OL>
+</BODY>
+</HTML>
-Follow the instructions in HOWTO to push the site changes to
-the Apache web site.
-
-13. Announce the release to the Apache community via email to
-announce@general.apache.org
-
-14. This step is only to avoid instructions with 13 steps.
Copied: db/jdo/trunk/README.html (from r670020, db/jdo/trunk/README.txt)
URL: http://svn.apache.org/viewvc/db/jdo/trunk/README.html?p2=db/jdo/trunk/README.html&p1=db/jdo/trunk/README.txt&r1=670020&r2=672352&rev=672352&view=diff
==============================================================================
--- db/jdo/trunk/README.txt (original)
+++ db/jdo/trunk/README.html Fri Jun 27 11:58:10 2008
@@ -1,29 +1,109 @@
-This is the official release of the JDO 2 project. It includes
-the JDO 2.0 TCK and its dependencies:
-
-- api20 contains source to build jdo.jar, which defines the JDO API version 2.0
-- core20 contains the JDO2 core, including utility and metadata model classes
-- enhancer20 contains the utility classes used for verifying enhanced files
-- tck20 contains the JDO 2.0 Technology Compatibility Kit
-
--------------
-Prerequisites
--------------
-
-- Maven
-You must have Maven version 1.0.1 or 1.0.2 to build the projects from source
-and to execute the TCK. You can download maven from
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>JDO 2.1 TCK README</TITLE>
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1>The JDO 2.1 Technology Compatibility Kit</H1>
+<UL>
+ <LI><a href="#overview">Overview</a></LI>
+ <!-- For minor release change documentation
+ <LI><a href="#changes">Changes since the last release</a></LI>
+ -->
+ <LI><a href="#prereqs">Prerequisites</a>
+ <UL>
+ <LI><a href="#maven">Maven</a></LI>
+ <LI><a href="#jndi">JNDI Implementation</a></LI>
+ </UL>
+ </LI>
+ <LI><a href="#building">Building the TCK from source</a></LI>
+ <LI><a href="#running">Running the TCK</a>
+ <UL>
+ <LI><a href="#goals">Custom Goals</a></LI>
+ <LI><a href="#cli">Command Line Options</a></LI>
+ <LI><a href="#files">Files</a></LI>
+ <LI><a href="#examples">Examples</a></LI>
+ </UL></LI>
+ </UL>
+<a name="overview"></a>
+<H2>Overview of the JDO 2.1 Technology Compatibility Kit</H2>
+<p>
+The JDO 2 project includes the JDO 2 TCK and its dependencies:
+</p>
+<UL>
+ <LI>api2 contains source to build jdo2-api-2.1.jar, which defines the JDO API version 2.1 for Java 1.5 and later.</LI>
+ <LI>api2-legacy contains source to build jdo2-api-legacy-2.1.jar, which defines the JDO API version 2.1 for Java 1.4 and earlier.</LI>
+ <LI>core20 contains the JDO2 core, including utility and metadata model classes</LI>
+ <LI>enhancer20 contains the utility classes used for verifying enhanced files</LI>
+ <LI>tck2 contains the JDO 2.1 Technology Compatibility Kit for Java 1.5 and later.</LI>
+ <LI>tck2-legacy contains the JDO 2.1 Technology Compatibility Kit for Java 1.4 and earlier.</LI>
+</UL>
+<p>
+JDO releases may be downloaded from <a href="http://db.apache.org/jdo/downloads.html">the Apache JDO downloads page</a>. Minor updates of releases are only available as source from the Subversion repository. Follow the instructions <a href="#building">below</a> to build the TCK from source.
+<p>
+For complete rules for certifying a JDO implementation,
+see RunRules.html in the top level tck2 or tck2-legacy project directory.
+</p>
+<!-- When creating a new minor release branch, list changes from the major release here
+
+<a name="changes"></a>
+<h2>Changes since the Major Release</h2>
+<p>
+</p>
+
+-->
+<a name="prereqs"></a>
+<h2>Prerequisites</h2>
+<p>
+You must install the software listed in the following sections
+to successfully run the TCK.
+Other dependencies, such as the reference implementation, DataNucleus,
+and the Apache Derby database, are downloaded automatically by maven.
+Note that Apache JDO uses the apache commons logging package for logging.
+</p>
+<a name="maven"></a>
+<h3>Maven</h3>
+<p>
+You must have Maven version 1.0.1, 1.0.2, or 1.1 to build the projects
+from source and to execute the TCK. You can download maven from
http://maven.apache.org/start/download.html
-
+</p><p>
Note that maven uses the user.home system property for the location
of the maven local repostitory: ${user.home}/.maven/repository.
-Under Windows this system property is C:\Documents and Settings\<user>
+Under Windows this system property is C:\Documents and Settings\<i>user</i>
no matter what the HOME variable is set to. As a workaround you may set the
system property by adding -Duser.home=%HOME% to the environment variable
MAVEN_OPTS.
-
-- JNDI implementation (fscontext.jar and providerutil.jar)
-The JNDI test cases in tck20 need a JNDI implementation.
+</p> <p>
+Mevenide is a nice maven plugin for IDEs available from http://mevenide.codehaus.org.
+In Netbeans, after you install the plugin, you can open an
+existing maven project by File -> Open Project -> Open Project Folder.
+Navigate to a directory including a maven project (e.g. api2) and choose this
+directory. Netbeans will create a project folder. If you right-click the Maven
+project you can examine the contents of the project.xml (see Properties) or
+execute goals.
+</p>
+<a name="jndi"></a>
+<h3>JNDI implementation (fscontext.jar and providerutil.jar)</h3>
+<p>
+The JNDI test cases in tck2 need a JNDI implementation.
The TCK is configured to use Sun's JNDI implementation.
To use your own implementation, put the implementation
jar files into lib/ext and update jndi.properties in the TCK directory
@@ -32,136 +112,111 @@
click the Download button at 'Download JNDI 1.2.1 & More', accept a license
agreement, download 'File System Service Provider, 1.2 Beta 3' and then unpack
the downloaded zip. It includes the jars fscontext.jar and providerutil.jar.
-
-- JPOX
-The Reference Implementation for JDO 2.0 is JPOX 1.1.0. The tck20 subproject
-automatically downloads the JPOX jar files via maven configuration.
-
-- derby
-The default datastore for tck20 is derby. The tck20 subproject
-automatically downloads version 10.1.1.0 of derby and derbytools.
-NOTE!! Mac OSX users must uncomment derby.storage.fileSyncTransactionLog=true
-in tck20/src/conf/derby.properties. For details, please see the Derby JIRA
-issue DERBY-1 at http://issues.apache.org/jira/browse/DERBY-1
-
--------
-Notes
--------
-
-- Logging
-Apache JDO uses the apache commons logging package for logging.
-
-- Checkstyle
-The file jdo_check.xml includes the checkstyle configuration. It is borrowed
-from the sun_checks.xml, but does not use all of the sun rules and customizes
-some other rules. The checkstyle configuration is not yet finished.
-
-- Mevenide
-Mevenide is a nice maven plugin for IDEs (see http://mevenide.codehaus.org).
-You find download instructions in http://mevenide.codehaus.org/download.html.
-For Netbeans, once you installed the plugin, you should be able to open an
-existing maven project by File -> Open Project -> Open Project Folder.
-Navigate to a directory including a maven project (e.g. api20) and choose this
-directory. Netbeans will create a project folder. If you right-click the Maven
-project you can examine the contents of the project.xml (see Properties) or
-execute goals.
-
--------
-Running the TCK
--------
-
-This version of the TCK is final.
-
-In the tck20 project, run "maven build" to build the tck. This will
+</p>
+<a name="building"></a>
+<h2>Building the TCK from Source</h2>
+For instructions for checking out the JDO source, see the Apache JDO <a href="http://db.apache.org/jdo/svn.html">source code</a> page.
+To build the TCK dependencies, change to the top level directory of the branch you are working in (or trunk if you are using the latest unreleased code) and run
+<pre>
+maven tck2.default
+</pre>
+Then change to the tck2 or tck2-legacy directory and run
+<pre>
+maven build
+</pre>
+When execution completes, you are ready to run the TCK.
+<p>
+<a name="running"></a>
+<h2>Running the TCK</h2>
+<p>
+In the tck2 project, run "maven build" to build the tck. This will
compile, enhance, install the schemas, and run all the tests on the RI on all
supported databases and identitytypes.
-
+</p>
+<p>
You may use the following custom goals and command line options
-with the tck20 project:
-
-Custom Goals:
- * help - displays help text describing custom goals and options
- * runtck.jdori - runs the TCK on the JDO Reference Implementation
- * runtck.iut - runs the TCK on the implementation under test
- * installSchema - installs the database schema
- * enhance.jdori - enhances the class files using the JDO RI enhancer
- * enhance.iut - enhances the class files using the
- implementation under test's enhancer
- * debugtck.jdori - waits for a debugger to attach and then runs the TCK
- on the JDO RI
- * debugtck.iut - waits for a debugger to attach and then runs the TCK
- on the implementation under test
-
-
-Command Line Options:
- -Djdo.tck.cfglist=<configuration file list>
- Overrides the definition of jdo.tck.cfglist found in
- tck20/src/conf/configuration.list by supplying
- one or more space-separated test configuration files.
- Test configuration files typically have the .conf extension.
- To run a single test, create a .conf file (copy an existing
- file) and put the test into the jdo.tck.classes property.
-
- -Djdo.tck.dblist=<database list>
- Overrides the property value in project.properties by supplying
- one or more space-separated database names
-
- -Djdo.tck.identitytypes=<identity type list>
- Overrides the property value in project.properties by supplying
- one or more space-separated identity types (applicationidentity
- or datastoreidentity) to use for this run.
-
- -Djdo.tck.cleanupaftertest=xxx - true/false. Setting it to false will
- retain data in database after test. This will allow inspection of
- data after test is run. Default is true
-
- -Djdo.tck.debug.port=##### - the port number the JVM should listen for
- a debugger on (default 8787)
-
- -Djdo.tck.debug.jvmargs=xxx - the "-Xdebug ..." arguments in the event
- you want to supply your own debug directives
-
-
-Maven looks for the following configuration files in src/conf:
- * configurations.list
- A list of files. Each file listed is a test configuration file.
- * test configuration files
- Each of these files sets values for
- jdo.tck.testdescription - an optional string describing
- the purpose of these tests
- jdo.tck.classes - a list of one or more test classes.
- jdo.tck.testdata - fully qualified file name
- (not required by all tests)
- jdo.tck.standarddata - fully qualified file name
- (not required by all tests)
- jdo.tck.mapping - file designator that maven.xml uses
- to build a javax.jdo.option.Mapping value and
- corresponding schema name
- * exclude.list
- A list of test classes NOT to execute during a TCK test run
-
-Examples:
- maven -Djdo.tck.identitytypes=datastoreidentity installSchema
- Installs the database schema for datastore identity for all
- supported databases
-
- maven -Djdo.tck.cfglist="alltests.conf cfg1.conf" runtck.jdori
- Runs the test configurations specified in alltests.conf and cfg1.conf
- on the JDORI, using all supported identity types and databases.
-
- maven -Djdo.tck.cfglist=detach.conf debugtck.jdori
- Runs the test detach.conf configuration, waiting for a debugger to
- attach on the default port
-
- maven -Djdo.tck.cfglist=detach.conf -Djdo.tck.debug.port=9343 debugtck.jdori
- Runs the test detach.conf configuration, waiting for a debugger to
- attach on port 9343
-
+with the tck2 project:
+</p>
+<a name="goals"></a>
+<h3>Custom Goals</h3>
+<DL>
+ <DT>help
+ <DD>displays help text describing custom goals and options
+ <DT>runtck.jdori
+ <DD>runs the TCK on the JDO Reference Implementation
+ <DT>runtck.iut
+ <DD>runs the TCK on the implementation under test
+ <DT>installSchema
+ <DD>installs the database schema
+ <DT>enhance.jdori
+ <DD>enhances the class files using the JDO RI enhancer
+ <DT>enhance.iut
+ <DD>enhances the class files using the implementation under test's enhancer
+ <DT>debugtck.jdori
+ <DD>waits for a debugger to attach and then runs the TCK on the JDO RI
+ <DT>debugtck.iut
+ <DD>waits for a debugger to attach and then runs the TCK on the implementation under test
+ <DT>cleanClasses
+ <DD>deletes classes and enhanced classes
+</DL>
+
+<a name="cli"></a>
+ <h3>Command Line Options</h3>
+ <DL>
+ <DT>-Djdo.tck.cfglist=<i>configuration file list</i><DD>Overrides the definition of jdo.tck.cfglist found in tck2/src/conf/configuration.list by supplying one or more space-separated test configuration files. Test configuration files typically have the .conf extension. To run a single test, create a .conf file (copy an existing file) and put the test into the jdo.tck.classes property.
+ <DT>-Djdo.tck.dblist=<i>database list</i><DD>Overrides the property value in project.properties by supplying one or more space-separated database names
+ <DT>-Djdo.tck.identitytypes=<i>identity type list</i><DD>Overrides the property value in project.properties by supplying one or more space-separated identity types (applicationidentity or datastoreidentity) to use for this run.
+ <DT>-Djdo.tck.cleanupaftertest=<i>boolean</i><DD>When false, data is retained in the database after the test. This allows inspection of data after test is run. Default is true.
+ <DT>-Djdo.tck.debug.port=<i>port number</i><DD>Sets the port number the JVM should listen for a debugger on. Default is 8787.
+ <DT>-Djdo.tck.debug.jvmargs=<i>args</i><DD>Sets the "-Xdebug ..." arguments to allow you to supply your own debug directives.
+</DL>
+<a name="files"></a>
+<h3>Files</h3>
+<p>Maven looks for the following configuration files in src/conf:
+<UL>
+ <LI>configurations.list
+ <br>A list of files. Each file listed is a test configuration file.</LI>
+ <LI>test configuration files (*.conf)
+ <br>Each of these files sets values for
+ <DL>
+ <DT>jdo.tck.testdescription
+ <DD>An optional string describing the purpose of these tests
+ <DT>jdo.tck.classes
+ <DD>A list of one or more test classes (required)
+ <DT>jdo.tck.testdata
+ <DD>The fully qualified file name of the xml test data file(optional)
+ <DT>jdo.tck.standarddata
+ <DD>The fully qualified file name of the xml test data file(optional)
+ <DT>jdo.tck.mapping
+ <DD>The file designator that maven.xml uses to build a javax.jdo.option.Mapping value and corresponding schema name (required)
+</DL></LI>
+ <LI>exclude.list
+ <br>A list of test classes NOT to execute during a TCK test run</LI>
+</UL>
+<a name="examples"></a>
+<h3>Examples</h3>
+<DL>
+ <DT>maven -Djdo.tck.identitytypes=datastoreidentity installSchema
+ <DD>Installs the database schema for datastore identity for all supported databases
+
+ <DT>maven -Djdo.tck.cfglist="alltests.conf cfg1.conf" runtck.jdori
+ <DD>Runs the test configurations specified in alltests.conf and cfg1.conf on the JDORI, using all supported identity types and databases.
+
+ <DT>maven -Djdo.tck.cfglist=detach.conf debugtck.jdori
+ <DD>Runs the test detach.conf configuration, waiting for a debugger to attach on the default port
+
+ <DT>maven -Djdo.tck.cfglist=detach.conf -Djdo.tck.debug.port=9343 debugtck.jdori
+ <DD>Runs the test detach.conf configuration, waiting for a debugger to attach on port 9343
+</DL>
+<p>
Note:
- By default, the database schema is NOT installed when the custom goals
- runtck.iut and runtck.jdori are run.
- maven build installs the database schema and runs the TCK on the
- JDO Reference Implementation.
- Enhancement is always done before running the TCK when the enhanced classes
- are not up to date.
+</p>
+<UL>
+ <LI type="none">By default, the database schema is NOT installed when the custom goals runtck.iut and runtck.jdori are run.</LI>
+ <LI type="none">maven build installs the database schema and runs the TCK on the JDO Reference Implementation.</LI>
+ <LI type="none">Enhancement is always done before running the TCK when the enhanced classes are not up to date.</LI>
+</UL>
+
+ </BODY>
+ </HTML>