[webbeans-commits] Webbeans SVN: r3210 - tck/trunk/doc/reference/en-US.

webbeans-commits at lists.jboss.org webbeans-commits at lists.jboss.org
Sat Jul 25 08:40:57 EDT 2009


Author: pete.muir at jboss.org
Date: 2009-07-25 08:40:57 -0400 (Sat, 25 Jul 2009)
New Revision: 3210

Added:
   tck/trunk/doc/reference/en-US/reporting.xml
Modified:
   tck/trunk/doc/reference/en-US/Author_Group.xml
   tck/trunk/doc/reference/en-US/Book_Preface.xml
   tck/trunk/doc/reference/en-US/configuration.xml
   tck/trunk/doc/reference/en-US/eclipse-debugging.xml
   tck/trunk/doc/reference/en-US/eclipse-running.xml
   tck/trunk/doc/reference/en-US/executing.xml
   tck/trunk/doc/reference/en-US/installation.xml
   tck/trunk/doc/reference/en-US/introduction.xml
   tck/trunk/doc/reference/en-US/part-background.xml
Log:
Use xref, not manual links, update intro, update eclipse-running

Modified: tck/trunk/doc/reference/en-US/Author_Group.xml
===================================================================
--- tck/trunk/doc/reference/en-US/Author_Group.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/Author_Group.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -7,7 +7,8 @@
       <firstname>Gavin</firstname>
       <surname>King</surname>
       <affiliation>
-         <jobtitle>JSR-299 specification lead</jobtitle>
+         <jobtitle>JSR-299: Contexts and Dependency Injection (CDI) for Java EE
+            specification lead</jobtitle>
          <orgname>Red Hat Middleware LLC</orgname>
       </affiliation>
    </author>
@@ -15,7 +16,7 @@
       <firstname>Pete</firstname>
       <surname>Muir</surname>
       <affiliation>
-         <jobtitle>JSR-299 TCK lead</jobtitle>
+         <jobtitle>CDI TCK lead</jobtitle>
          <orgname>Red Hat Middleware LLC</orgname>
       </affiliation>
    </author>
@@ -23,7 +24,7 @@
       <firstname>Dan</firstname>
       <surname>Allen</surname>
       <affiliation>
-         <jobtitle>JSR-299 TCK developer</jobtitle>
+         <jobtitle>CDI TCK developer</jobtitle>
          <orgname>Red Hat Middleware LLC</orgname>
       </affiliation>
    </author>

Modified: tck/trunk/doc/reference/en-US/Book_Preface.xml
===================================================================
--- tck/trunk/doc/reference/en-US/Book_Preface.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/Book_Preface.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -5,15 +5,14 @@
 
    <para>
       This guide describes how to download, install, configure, and run the
-      Technology Compatibility Kit (TCK) used to verify the compatibility of a
-      licensee&apos;s implementation of the JSR-299: Context and Dependency
-      Injection for Java EE (CDI) specification.
+      Technology Compatibility Kit (TCK) used to verify the compatibility of an
+      implementation of the JSR-299: Context and Dependency Injection for Java
+      EE (CDI) specification.
    </para>
    <para>
       The CDI TCK is built atop the JBoss Test Harness, a portable and
       configurable automated test suite for authoring unit and integration tests
-      in a Java EE environment. The CDI TCK 1.0.0 uses the JBoss Test
-      Harness
+      in a Java EE environment. The CDI TCK 1.0.0 uses the JBoss Test Harness
       version 1.0.0 to execute the test suite.
    </para>
 
@@ -47,9 +46,8 @@
          web site.
       </para>
       <para>
-         The CDI TCK is based on the Context and Dependency Injection for
-         Java EE
-         technology specification 1.0 (JSR-299). Information about the
+         The CDI TCK is based on the Context and Dependency Injection for Java
+         EE technology specification 1.0 (JSR-299). Information about the
          specification, including links to the specification documents, can be
          found on the
          <ulink url="http://jcp.org/en/jsr/detail?id=299">JSR-299 JCP page</ulink>
@@ -68,67 +66,85 @@
 
       <title>How This Book Is Organized</title>
       <para>
-         If you are running the CDI TCK for the first time, read Chapter
-         1 and
-         Chapter 2 completely for the necessary background information
-         about the
-         TCK and its purpose. Once you have reviewed that material,
-         perform the
-         steps outlined in the remaining chapters.
+         If you are running the CDI TCK for the first time, read
+         <xref linkend="introduction" />
+         and
+         <xref linkend="test-harness-introduction" />
+         completely for the necessary background information about the TCK and
+         the Test Harness purpose. Once you have reviewed that material, perform
+         the steps outlined in the remaining chapters.
       </para>
       <itemizedlist>
          <listitem>
             <para>
-               Chapter 1 gives an overview of the principles that apply
-               generally to all Technology Compatibility Kits (TCKs) and
-               describes the CDI TCK architecture and components. It also
-               includes a broad overview of how the TCK is executed and lists
-               the platforms on which the TCK has been tested and verified.
+               <xref linkend="introduction" />
+               gives an overview of the principles that apply generally to all
+               Technology Compatibility Kits (TCKs) and describes the CDI TCK
+               architecture and components. It also includes a broad overview of
+               how the TCK is executed and lists the platforms on which the TCK
+               has been tested and verified.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 2 explains where to obtain the required software and
-               how to install it. It covers both the primary TCK components as
-               well as tools useful for troubleshooting tests.
+               <xref linkend="installation" />
+               explains where to obtain the required software and how to install
+               it. It covers both the primary TCK components as well as tools
+               useful for troubleshooting tests.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 3 details the configuration of the JBoss Test Harness,
-               how to create a TCK runner for the TCK test suite and the
-               mechanics of how an in-container test is conducted.
+               <xref linkend="configuration" />
+               details the configuration of the JBoss Test Harness, how to
+               create a TCK runner for the TCK test suite and the mechanics of
+               how an in-container test is conducted.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 4 documents how the TCK test suite is executed. It
-               covers both modes supported by the TCK, standalone and
-               in-container, and shows how to dump the generated test artifacts
-               to disk.
+               <xref linkend="reporting" />
+               explains the test reports that are generated by the TCK test
+               suite and introduces the TCK audit report as a tool for measuring
+               the completeness of the TCK in testing the JSR-299 specification
+               and in understanding how testcases relate to the specification.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 5 shows how to run individual tests in Eclipse and
-               advices the best way to setup your Eclipse workspace for running
-               the tests.
+               <xref linkend="executing" />
+               documents how the TCK test suite is executed. It covers both
+               modes supported by the TCK, standalone and in-container, and
+               shows how to dump the generated test artifacts to disk.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 6 builds on chapter 5 by detailing how to debug
-               individual tests in Eclipse.
+               <xref linkend="eclipse-running" />
+               shows how to run individual tests in Eclipse and advises the best
+               way to setup your Eclipse workspace for running the tests.
             </para>
          </listitem>
          <listitem>
             <para>
-               Chapter 7 (pending) explains the test reports that are
-               generated by the TCK test suite and introduces the TCK audit
-               report as a tool for measure a licensee&apos;s progress in
-               passing the TCK.
+               <xref linkend="eclipse-debugging" />
+               builds on
+               <xref linkend="eclipse-running" />
+               by detailing how to debug individual tests in Eclipse.
             </para>
          </listitem>
+         <listitem>
+            <para>
+               <xref linkend="test-harness" />
+               includes excerpts from the JBoss Test Harness Reference Guide.
+               How to configure the JBoss Test Harness as it relates to the CDI
+               TCK is presented in
+               <xref linkend="configuration" />
+               however to aid in debugging or configuring the TCK in your
+               environment, you may want to read in more detail how to use the
+               JBoss Test Harness.
+            </para>
+         </listitem>
       </itemizedlist>
    </section>
 </preface>

Modified: tck/trunk/doc/reference/en-US/configuration.xml
===================================================================
--- tck/trunk/doc/reference/en-US/configuration.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/configuration.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -122,8 +122,8 @@
       <para>
          The CDI TCK relies on an implementation of the porting package to
          function. The porting package can be divided into two parts. The first
-         part is comprised of extensions to the JSR-299 SPIs to allow testing of
-         a container. The second part must implement the JBoss Test Harness
+         part is comprised of extensions to the CDI SPIs to allow testing of a
+         container. The second part must implement the JBoss Test Harness
          artifact deployment APIs for deploying artifacts to the Java EE
          container.
       </para>
@@ -135,7 +135,7 @@
          implementation.
       </para>
       <para>
-         The four SPI classes in the JSR-299 TCK are as follows:
+         The four SPI classes in the CDI TCK are as follows:
       </para>
       <itemizedlist>
          <listitem>

Modified: tck/trunk/doc/reference/en-US/eclipse-debugging.xml
===================================================================
--- tck/trunk/doc/reference/en-US/eclipse-debugging.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/eclipse-debugging.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -1,55 +1,111 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
 <chapter id="eclipse-debugging">
-  <title>Debugging Tests in Eclipse</title>
-  <para>This chapter explains how to debug standalone tests and integration tests from the TCK test suite in Eclipse. You should be able to use the lessons learned here to debug tests in an alternate IDE.</para>
-  <section>
-    <title>Debugging a standalone test</title>
-    <para>There is almost no difference in how you debug a standalone test from how you run it. With the test class open in the Eclipse editor, simply right click in the editor view and select TestNG &gt; Debug as test. Eclipse will stop at any breakpoints you set just like it would with any other local debug process.</para>
-    <para>If you plan to step into a class in a JSR-299 implementation (or any other dependent library), you must ensure that the source is properly associated with the library. Below are the steps to follow to associate the source of the JSR-299 RI with the TestNG debug configuration: </para>
-    <orderedlist>
-      <listitem>
-        <para>Select the Run &gt; Debug Configurations... menu from the main menubar</para>
-      </listitem>
-      <listitem>
-        <para>Select the name of the test class in the TestNG category</para>
-      </listitem>
-      <listitem>
-        <para>Select the Source tab</para>
-      </listitem>
-      <listitem>
-        <para>Click the Add... button on the right</para>
-      </listitem>
-      <listitem>
-        <para>Select Java Project</para>
-      </listitem>
-      <listitem>
-        <para>Check the project the contains the class you want to debug (e.g., webbeans-core)</para>
-      </listitem>
-      <listitem>
-        <para>Click OK on the Project Selection window</para>
-      </listitem>
-      <listitem>
-        <para>Click Close on the Debug Configurations window</para>
-      </listitem>
-    </orderedlist>
-    <para>You&apos;ll have to complete those steps for any test class you are debugging, though you only have to do it once (the debug configuration hangs around indefinitely).</para>
-    <para>Again, running a test in standalone isn&apos;t enough to pass the TCK and cannot be used to run or debug an integration test. Let&apos;s look at how to debug a test running in the context of the container.</para>
-  </section>
-  <section>
-    <title>Debugging an integration test</title>
-    <para>In order to debug an integration test, or any test run in in-container mode, the test must be configured to run in-container, as described in section  6.4, and you must  attach the IDE debugger to the container. That puts the debugger on both sides of the fence, so to speak.</para>
-    <para>Since setting up a test to run in-container has already been covered, we&apos;ll look at how to attach the IDE debugger to the container, and then move on launching the test in debug mode.</para>
-    <section>
-      <title>Attaching the IDE debugger to the container</title>
-      <para>There are two ways to attach the IDE debugger to the container. You can either start the container in debug mode from within the IDE, or you can attach the debugger over a socket connection to a standalone container running with JPDA enabled.</para>
-      <para>The Eclipse Server Tools, a subproject of the Eclipse Web Tools Project (WTP), has support for launching most major application servers, including JBoss AS 5. However, if you are using JBoss AS, you should consider using JBoss Tools instead, which offers tighter integration with JBoss technologies. See either the <ulink url="http://www.eclipse.org/webtools/server/server.php">Server Tools documentation</ulink> or the <ulink url="http://docs.jboss.org/tools/3.0.1.GA/en/as/html/index.html">JBoss Tools documentation</ulink> for how to setup a container and start it in debug mode.</para>
-      <para>See <ulink url="http://maverikpro.wordpress.com/2007/11/26/remote-debug-a-web-application-using-eclipse">this blog entry</ulink> to learn how to start JBoss with JPDA enabled and how to get the Eclipse debugger to connect to the remote process.</para>
-    </section>
-    <section>
-      <title>Launching the test in the debugger</title>
-      <para>Once Eclipse is debugging the container, you can set a breakpoint in the test and debug it just like a standalone test. Open a test annotated with <literal>@IntegrationTest</literal> in the Eclipse editor, right click in the editor view, and select TestNG &gt; Debug as test.  The only difference is that when the IDE hits the breakpoint this time, it halts the JVM thread of the container rather than the thread that launched the test.</para>
-      <para>Remember that if you need to debug into dependent libraries, the source code for those libraries needs to be registered with the TestNG debug configuration as described in the first section in this chapter.</para>
-    </section>
-  </section>
+   <title>Debugging Tests in Eclipse</title>
+   <para>This chapter explains how to debug standalone tests and integration
+      tests from the TCK test suite in Eclipse. You should be able to use the
+      lessons learned here to debug tests in an alternate IDE.</para>
+   <section>
+      <title>Debugging a standalone test</title>
+      <para>There is almost no difference in how you debug a standalone test
+         from how you run it. With the test class open in the Eclipse editor,
+         simply right click in the editor view and select TestNG &gt; Debug as
+         test. Eclipse will stop at any breakpoints you set just like it would
+         with any other local debug process.</para>
+      <para>If you plan to step into a class in a Web BEans implementation (or
+         any other dependent library), you must ensure that the source is
+         properly associated with the library. Below are the steps to follow to
+         associate the source of the Web Beans with the TestNG debug
+         configuration:
+      </para>
+      <orderedlist>
+         <listitem>
+            <para>Select the Run &gt; Debug Configurations... menu from the main
+               menubar</para>
+         </listitem>
+         <listitem>
+            <para>Select the name of the test class in the TestNG category
+            </para>
+         </listitem>
+         <listitem>
+            <para>Select the Source tab</para>
+         </listitem>
+         <listitem>
+            <para>Click the Add... button on the right</para>
+         </listitem>
+         <listitem>
+            <para>Select Java Project</para>
+         </listitem>
+         <listitem>
+            <para>Check the project the contains the class you want to debug
+               (e.g., webbeans-core)</para>
+         </listitem>
+         <listitem>
+            <para>Click OK on the Project Selection window</para>
+         </listitem>
+         <listitem>
+            <para>Click Close on the Debug Configurations window</para>
+         </listitem>
+      </orderedlist>
+      <para>You&apos;ll have to complete those steps for any test class you are
+         debugging, though you only have to do it once (the debug configuration
+         hangs around indefinitely).</para>
+      <para>Again, running a test in standalone isn&apos;t enough to pass the
+         TCK and cannot be used to run or debug an integration test. Let&apos;s
+         look at how to debug a test running in the context of the container.
+      </para>
+   </section>
+   <section>
+      <title>Debugging an integration test</title>
+      <para>In order to debug an integration test, or any test run in
+         in-container mode, the test must be configured to run in-container, as
+         described in section 6.4, and you must attach the IDE debugger to the
+         container. That puts the debugger on both sides of the fence, so to
+         speak.</para>
+      <para>Since setting up a test to run in-container has already been
+         covered, we&apos;ll look at how to attach the IDE debugger to the
+         container, and then move on launching the test in debug mode.</para>
+      <section>
+         <title>Attaching the IDE debugger to the container</title>
+         <para>There are two ways to attach the IDE debugger to the container.
+            You can either start the container in debug mode from within the
+            IDE, or you can attach the debugger over a socket connection to a
+            standalone container running with JPDA enabled.</para>
+         <para>
+            The Eclipse Server Tools, a subproject of the Eclipse Web Tools
+            Project (WTP), has support for launching most major application
+            servers, including JBoss AS 5. However, if you are using JBoss AS,
+            you should consider using JBoss Tools instead, which offers tighter
+            integration with JBoss technologies. See either the
+            <ulink url="http://www.eclipse.org/webtools/server/server.php">Server Tools documentation</ulink>
+            or the
+            <ulink url="http://docs.jboss.org/tools/3.0.1.GA/en/as/html/index.html">JBoss Tools documentation</ulink>
+            for how to setup a container and start it in debug mode.
+         </para>
+         <para>
+            See
+            <ulink
+               url="http://maverikpro.wordpress.com/2007/11/26/remote-debug-a-web-application-using-eclipse">this blog entry</ulink>
+            to learn how to start JBoss with JPDA enabled and how to get the
+            Eclipse debugger to connect to the remote process.
+         </para>
+      </section>
+      <section>
+         <title>Launching the test in the debugger</title>
+         <para>
+            Once Eclipse is debugging the container, you can set a breakpoint in
+            the test and debug it just like a standalone test. Open a test
+            annotated with
+            <literal>@IntegrationTest</literal>
+            in the Eclipse editor, right click in the editor view, and select
+            TestNG &gt; Debug as test. The only difference is that when the IDE
+            hits the breakpoint this time, it halts the JVM thread of the
+            container rather than the thread that launched the test.
+         </para>
+         <para>Remember that if you need to debug into dependent libraries, the
+            source code for those libraries needs to be registered with the
+            TestNG debug configuration as described in the first section in this
+            chapter.</para>
+      </section>
+   </section>
 </chapter>

Modified: tck/trunk/doc/reference/en-US/eclipse-running.xml
===================================================================
--- tck/trunk/doc/reference/en-US/eclipse-running.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/eclipse-running.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -12,11 +12,10 @@
    <section>
       <title>Leveraging Eclipse's plugin ecosystem</title>
       <para>
-         The primary motivation for building the test harness on top of an
-         existing testing framework is to allow the tests to be executed and
+         Using an existing test harness allows the tests to be executed and
          debugged in an Integrated Development Environment (IDE) using available
-         plugins. It's also the easiest way to execute a test class in
-         isolation.
+         plugins. Using an IDE is also the easiest way to execute a test class
+         in isolation.
       </para>
       <para>
          The TCK can be executed in any IDE for which there is a TestNG
@@ -28,28 +27,46 @@
          Before running a test from the TCK test suite in Eclipse, you must have
          the Eclipse
          <ulink url="http://testng.org">TestNG plugin</ulink>
-         and the m2eclipse plugin installed. Refer to section 2.2.2 for more
-         information on these plugins.
+         and should either install the m2eclipse plugin installed or use the
+         <literal>maven-eclipse-plugin</literal>
+         . Refer to
+         <xref linkend="eclipse-plugins" />
+         for more information on these plugins.
       </para>
+
       <para>
          With the m2eclipse plugin installed, Eclipse should recognize the
-         JSR-299 TCK projects as valid Eclipse projects (or any Web Beans
-         project for that matter). Import them into the Eclipse workspace at
-         this time. You should also import the JSR-299 RI projects if you want
-         to debug into that code, which is covered later.
+         CDI TCK projects as valid Eclipse projects (or any Web Beans project
+         for that matter). Import them into the Eclipse workspace at this time.
+         You should also import the Web Beans projects if you want to debug into
+         that code, which is covered later.
       </para>
+      <tip>
+         <para>
+            If you choose to use the
+            <literal>maven-eclipse-plugin</literal>
+            you
+            should execute the plugin in both the tck and webbeans:
+         </para>
+         <programlisting><![CDATA[cd tck
+mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs
+cd ../webbeans
+mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs]]></programlisting>
+      </tip>
    </section>
    <section>
       <title>Readying the Eclipse workspace</title>
       <para>
          When setting up your Ecilpse workspace, I recommend creating three
-         workings sets: one for the JSR-299 RI (Web Beans), one for the JSR-299
-         TCK and one for the JBoss TCK Runner. The dependencies between the
-         projects will be established automatically by the m2eclipse plugin
-         based on the dependency information in the pom.xml files. Your
-         workspace should appear as follows:
+         workings sets: one for the Web Beans, one for the CDI TCK and one for
+         the JBoss TCK Runner. The dependencies between the projects will be
+         established (either automatically by the m2eclipse plugin based on the
+         dependency information in the pom.xml files, or previously created by
+         the
+         <literal>maven-eclipse-plugin</literal>
+         . Your workspace should appear as follows:
       </para>
-      <programlisting>JSR-299 RI
+      <programlisting><![CDATA[Web Beans
   jsr299-api
   webbeans-api
   webbeans-core
@@ -58,23 +75,26 @@
   webbeans-parent
   webbeans-spi
   webbeans-version-matrix
-JSR-299 TCK
+CDI TCK
   jsr299-tck-api
   jsr299-tck-impl
   parent
 Web Beans JBoss TCK Runner
   webbeans-jboss-tck-runner
-  webbeans-porting-package</programlisting>
+  webbeans-porting-package]]></programlisting>
       <para>
          The tests in the TCK test suite are located in the jsr299-tck-impl
          project. You'll be working within this project in Eclipse when you are
          developing tests. However, you learned earlier, there are no references
-         to a JSR-299 implementation in the TCK. So how can you execute an
+         to a CDI implementation in the TCK. So how can you execute an
          individual test in Eclipse? The secret is that you need to establish a
          link in Eclipse (not in Maven) between the jsr299-tck-impl project and
          your TCK runner project, which in this case is
-         webbeans-jboss-tck-runner. Here are the steps to establish the link:
+         webbeans-jboss-tck-runner.
       </para>
+      <para>
+         Here are the steps to establish the link:
+      </para>
       <orderedlist>
          <listitem>
             <para>
@@ -114,10 +134,50 @@
          </listitem>
       </orderedlist>
       <para>
-         The TCK runner project should pull in the JSR-299 implementation,
-         the TCK porting package and any additional properties that must be
-         defined to execute the TCK test suite.
+         Of course, the webbeans-jboss-tck-runner also depends on the
+         jsr299-tck-impl at runtime (so that it can actually access the tests to
+         execute). So, now we have a cycle in the dependency graph, and in all
+         likelihood Eclipse will refuse to compile one or more projects.
+         However,
+         <emphasis>we</emphasis>
+         don't need the TCK runner to access tests when debugging (we'll use the
+         TestNG plugin to execute the tests) - we just need access to it's
+         classes, configuration, and other dependencies. So, we remove it's
+         dependence on the jsr299-tck-impl project:
       </para>
+      <orderedlist>
+         <listitem>
+            <para>
+               Right click on the webbeans-jboss-tck-runner project
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               Select Build Path &gt; Configure Build Path...
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               Click on the Projects tab
+            </para>
+         </listitem>
+         a
+         <listitem>
+            <para>
+               Select the TCK tests project (jsr299-tck-impl)
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               Click the Remove button on the right
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               Click the OK button on the Java Build Path window
+            </para>
+         </listitem>
+      </orderedlist>
    </section>
    <section>
       <title>Running a test in standalone mode</title>
@@ -142,7 +202,7 @@
       <para>
          So far you have executed a test in standalone mode. That's not
          sufficient to pass the TCK. The test must be executed in in-container
-         mode. Using in-container mode also the only way to execute a test
+         mode. Using in-container mode is also the only way to execute a test
          annotated with
          <literal>@IntegrationTest</literal>
          as it requires container resources. So let's see what has to be done to
@@ -168,7 +228,9 @@
       <para>
          The JBoss TCK runner project conveniently provides the properties file
          src/test/debug-resources/META-INF/jboss-test-harness.properties that
-         contains all of the necessary properties. You may have to tune the
+         contains all of the necessary properties. Assuming you followed the
+         recommended directory structure, you are good to go, otherwise you may
+         have to tune the
          <literal>org.jboss.testharness.container.extraConfigurationDir
          </literal>
          and
@@ -344,8 +406,7 @@
          </listitem>
       </orderedlist>
       <para>
-         Now you don't have to do any special configuration for each
-         test
+         Now you don't have to do any special configuration for each test
          class.
       </para>
       <para>
@@ -354,10 +415,9 @@
          Eclipse classpath. 
       </para>
       <para>
-         You have now mastered running the JSR-299 TCK against the JSR-299 RI
-         using both Maven 2 and within Eclipse. Now you're likely interested in
-         how to debug a test so that you can efficiently investigate test
-         failures.
+         You have now mastered running the CDI TCK against Web Beans using
+         both Maven 2 and within Eclipse. Now you're likely interested in how to
+         debug a test so that you can efficiently investigate test failures.
       </para>
    </section>
 </chapter>

Modified: tck/trunk/doc/reference/en-US/executing.xml
===================================================================
--- tck/trunk/doc/reference/en-US/executing.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/executing.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -3,11 +3,11 @@
 <chapter id="executing">
    <title>Executing the Test Suite</title>
    <para>
-      This chapter explains how to run the TCK on the JSR-299 RI as well as
-      your own implementation. The JSR-299 TCK uses the Maven 2 TestNG plugin
-      and the JBoss Test Harness to execute the test suite. Learning to execute
-      the test suite from Maven 2 is prerequisite knowlege for running the tests
-      in an IDE, such as Eclipse.
+      This chapter explains how to run the TCK on Web Beans as well as your
+      own implementation. The CDI TCK uses the Maven 2 TestNG plugin and the
+      JBoss Test Harness to execute the test suite. Learning to execute the test
+      suite from Maven 2 is prerequisite knowlege for running the tests in an
+      IDE, such as Eclipse.
    </para>
    <section>
       <title>The Test Suite Runner</title>
@@ -16,14 +16,10 @@
          The test suite is executed by the Maven 2 TestNG plugin during the test
          phase of the Maven 2 life cycle. The execution happens within a TCK
          runner project (as opposed to the TCK project itself). Web Beans
-         includes a TCK runner project that executes the CDI TCK on the
-         Web Beans
-         running inside JBoss AS 5.1. To execute the
-         CDI TCK on your own JSR-299
-         implementation, you could modify the TCK
-         runner project included with
-         Web Beans to use your JSR-299
-         implementation as described in
+         includes a TCK runner project that executes the CDI TCK on Web Beans
+         running inside JBoss AS 5.1. To execute the CDI TCK on your own CDI
+         implementation, you could modify the TCK runner project included with
+         Web Beans to use your CDI implementation as described in
          <xref linkend="configuration" />
       </para>
    </section>
@@ -132,7 +128,9 @@
          directory.
       </para>
       <para>
-         You can read more about this in <xref linkend="dumping-test-artifacts"/>.
+         You can read more about this in
+         <xref linkend="dumping-test-artifacts" />
+         .
       </para>
    </section>
 </chapter>

Modified: tck/trunk/doc/reference/en-US/installation.xml
===================================================================
--- tck/trunk/doc/reference/en-US/installation.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/installation.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -11,10 +11,10 @@
       <para>
          You can obtain a release of the CDI TCK project from the from the
          <ulink url="http://seamframework.org/Download">download page</ulink>
-         on Seam Framework website. The JSR-299 TCK is distributed as a ZIP
-         file, which contains the TCK artifacts (the test suite binary and
-         source, porting package API binary and source, the test suite
-         descriptor, the audit source and report) in
+         on Seam Framework website. The CDI TCK is distributed as a ZIP file,
+         which contains the TCK artifacts (the test suite binary and source,
+         porting package API binary and source, the test suite descriptor, the
+         audit source and report) in
          <code>/artifacts</code>
          , the TCK library dependencies in
          <code>/lib</code>
@@ -107,9 +107,9 @@
          annotation on the class). All test methods (i.e., methods annotated
          with
          <literal>@Test</literal>
-         ) in the test class are run in the same JSR-299 root context, meaning
-         bean discovery occurs exactly once per artifact and the same
-         BeanManager is used by each test method in the class.
+         ) in the test class are run in the application, meaning bean discovery
+         occurs exactly once per artifact and the same BeanManager is used by
+         each test method in the class.
       </para>
 
       <tip id="tck-in-jboss-as">
@@ -211,7 +211,7 @@
 
       </tip>
    </section>
-   <section>
+   <section id="eclipse-plugins">
       <title>Eclipse plugins</title>
       <para>
          Eclipse, or any other IDE, is not required to execute or pass the

Modified: tck/trunk/doc/reference/en-US/introduction.xml
===================================================================
--- tck/trunk/doc/reference/en-US/introduction.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/introduction.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -5,7 +5,7 @@
 
    <para>
       This chapter explains the purpose of a TCK and identifies the
-      foundation elements of the JSR-299 TCK.
+      foundation elements of the CDI TCK.
    </para>
    <section>
       <title>TCK Primer</title>
@@ -33,9 +33,9 @@
          However, when the information returned by the public API is not
          low-level enough to validate the assertion, the implementation must be
          consulted directly. In this case, the TCK provides an independent API
-         as part of a porting package which must also be implemented by the
-         licensee. Section 1.3.4 introduces the porting package and section 4.1
-         covers the requirements for implementing it.
+         as part of a porting package which must also be implemented. Section
+         1.3.4 introduces the porting package and section 4.1 covers the
+         requirements for implementing it.
       </para>
    </section>
    <section>
@@ -239,7 +239,7 @@
             <listitem>
                <para>
                   <emphasis role="bold">The TCK audit</emphasis>
-                  is used to list out the assertions identified in the JSR-299
+                  is used to list out the assertions identified in the CDI
                   specification. It matches the assertions to testcases in the
                   test suite and produces a coverage report.
                </para>

Modified: tck/trunk/doc/reference/en-US/part-background.xml
===================================================================
--- tck/trunk/doc/reference/en-US/part-background.xml	2009-07-25 11:19:40 UTC (rev 3209)
+++ tck/trunk/doc/reference/en-US/part-background.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -11,13 +11,17 @@
          the TCK.
       </para>
       <para>
-         In this part you will learn where to obtain the JSR-299 TCK and
+         In this part you will learn where to obtain the CDI TCK and
          supporting software. You are then presented with recommendations of how
          to organize and configure the software so that you are ready to execute
          the TCK.
       </para>
+      <para>
+         Finally, it discusses the reporting provided by the TCK.
+      </para>
    </partintro>
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="introduction.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="installation.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="configuration.xml" />
+   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="reporting.xml" />
 </part>

Added: tck/trunk/doc/reference/en-US/reporting.xml
===================================================================
--- tck/trunk/doc/reference/en-US/reporting.xml	                        (rev 0)
+++ tck/trunk/doc/reference/en-US/reporting.xml	2009-07-25 12:40:57 UTC (rev 3210)
@@ -0,0 +1,6 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
+<chapter id="reporting">
+   <title>Reporting</title>
+   <para>TODO</para>
+</chapter>


Property changes on: tck/trunk/doc/reference/en-US/reporting.xml
___________________________________________________________________
Name: svn:mime-type
   + text/plain




More information about the weld-commits mailing list