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

webbeans-commits at lists.jboss.org webbeans-commits at lists.jboss.org
Wed Jul 29 00:40:07 EDT 2009


Author: dan.j.allen
Date: 2009-07-29 00:40:05 -0400 (Wed, 29 Jul 2009)
New Revision: 3342

Modified:
   tck/trunk/doc/reference/en-US/Author_Group.xml
   tck/trunk/doc/reference/en-US/Book_Info.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/master.xml
   tck/trunk/doc/reference/en-US/part-background.xml
   tck/trunk/doc/reference/en-US/part-execution.xml
   tck/trunk/doc/reference/en-US/part-test-harness.xml
   tck/trunk/doc/reference/en-US/reporting.xml
Log:
minor revisions and rephrasings
some reformatting as needed


Modified: tck/trunk/doc/reference/en-US/Author_Group.xml
===================================================================
--- tck/trunk/doc/reference/en-US/Author_Group.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/Author_Group.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -28,4 +28,7 @@
          <orgname>Red Hat Middleware LLC</orgname>
       </affiliation>
    </author>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </authorgroup>

Modified: tck/trunk/doc/reference/en-US/Book_Info.xml
===================================================================
--- tck/trunk/doc/reference/en-US/Book_Info.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/Book_Info.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -22,4 +22,7 @@
       Dependency Injection for Java EE</title>
    <subtitle>Specification Lead: Red Hat Middleware LLC</subtitle>
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Author_Group.xml" />
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </bookinfo>

Modified: tck/trunk/doc/reference/en-US/Book_Preface.xml
===================================================================
--- tck/trunk/doc/reference/en-US/Book_Preface.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/Book_Preface.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -145,4 +145,7 @@
          </listitem>
       </itemizedlist>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </preface>

Modified: tck/trunk/doc/reference/en-US/configuration.xml
===================================================================
--- tck/trunk/doc/reference/en-US/configuration.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/configuration.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -12,7 +12,7 @@
    </para>
 
    <para>
-      This guide does not discuss in detail how to use the TCK in standalone
+      This chapter does not discuss in detail how to use the TCK in standalone
       mode. The JBoss Test Harness guide provides more on running in standalone
       mode.
    </para>
@@ -219,4 +219,7 @@
       </para>
 
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/eclipse-debugging.xml
===================================================================
--- tck/trunk/doc/reference/en-US/eclipse-debugging.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/eclipse-debugging.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -3,25 +3,24 @@
 <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.
+      This chapter explains how to debug standalone 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 as well.
    </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
+         simply right click in the editor view and select Debug As &gt; TestNG
+         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:
+         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 Web Beans with the TestNG debug configuration:
       </para>
       <orderedlist>
          <listitem>
@@ -81,10 +80,10 @@
    <section>
       <title>Debugging an integration test</title>
       <para>
-         In order to debug an integration test, or any test run in in-container
+         In order to debug an integration test, or any test run using in-container
          mode, the test must be configured to run in-container, as described in
-         <xref linkend="eclipse-in-container" />
-         , and you must attach the IDE debugger to the container. That puts the
+         <xref linkend="eclipse-in-container" />,
+         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>
@@ -115,7 +114,7 @@
             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
+            to learn how to start JBoss AS with JPDA enabled and how to get the
             Eclipse debugger to connect to the remote process.
          </para>
       </section>
@@ -123,20 +122,25 @@
          <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.
+            the test and debug it just like a standalone test. Let's give it a
+            try.
          </para>
          <para>
+            Open a test annotated with <literal>@IntegrationTest</literal> in
+            the Eclipse editor, right click in the editor view, and select Debug
+            As &gt; TestNG Test. This time when the IDE hits the breakpoint, 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
+            source code for those libraries will need to be registered with the
             TestNG debug configuration as described in the first section in this
             chapter.
          </para>
       </section>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/eclipse-running.xml
===================================================================
--- tck/trunk/doc/reference/en-US/eclipse-running.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/eclipse-running.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -7,31 +7,31 @@
       TestNG plugin. It covers running non-integration tests in standalone mode
       and integration tests (as well as non-integration tests) in in-container
       mode. You should be able to use the lessons learned here to debug tests in
-      an alternate IDE.
+      an alternate IDE as well.
    </para>
    <section>
       <title>Leveraging Eclipse's plugin ecosystem</title>
       <para>
-         Using an existing test harness allows the tests to be executed and
-         debugged in an Integrated Development Environment (IDE) using available
-         plugins. Using an IDE is also the easiest way to execute a test class
-         in isolation.
+         Using an existing test harness (TestNG) allows the tests to be executed
+         and debugged in an Integrated Development Environment (IDE) using
+         available 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
-         plugin available. Running a test in Eclipse is almost as simple as
-         running the test with the Eclipse TestNG plugin. You can also use the
-         plugin to debug a test, which is described in the next chapter.
+         The TCK can be executed in any IDE for which there is a TestNG plugin
+         available. Running a test from the CDI TCK test suite using the Eclipse
+         TestNG plugin is almost as simple as running any other TestNG test. You
+         can also use the plugin to debug a test, which is described in the next
+         chapter.
       </para>
       <para>
          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 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.
+         the Eclipse <ulink url="http://testng.org">TestNG plugin</ulink> and
+         either the m2eclipse plugin or an Eclipse project generated use the
+         Maven 2 Eclipse plugin (<literal>maven-eclipse-plugin</literal>). Refer
+         to <xref linkend="eclipse-plugins" /> for more information on these
+         plugins.
       </para>
 
       <para>
@@ -43,10 +43,9 @@
       </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:
+            If you choose to use the Maven 2 Eclipse plugin
+            (<literal>maven-eclipse-plugin</literal>), you should execute the
+            plugin in both the tck and webbeans projects:
          </para>
          <programlisting><![CDATA[cd tck
 mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs
@@ -57,15 +56,39 @@
    <section>
       <title>Readying the Eclipse workspace</title>
       <para>
-         When setting up your Ecilpse workspace, I recommend creating three
-         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:
+         When setting up your Ecilpse workspace, we recommended creating three
+         workings sets:
       </para>
+      <orderedlist>
+         <listitem>
+            <para>
+               <emphasis role="bold">Web Beans</emphasis> - Groups the CDI API
+               and the CDI RI (i.e., Web Beans) projects
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               <emphasis role="bold">CDI TCK</emphasis> - Groups the CDI TCK
+               API and the test suite projects
+            </para>
+         </listitem>
+         <listitem>
+            <para>
+               <emphasis role="bold">Web Beans JBoss TCK Runner</emphasis> -
+               Groups the porting package implementation and TCK runner projects
+               that are configured to certify Web Beans deployed on JBoss AS 5.1
+            </para>
+         </listitem>
+      </orderedlist>
+      <para> 
+         The dependencies between the projects will either be established
+         automatically by the m2eclipse plugin, based on the dependency
+         information in the pom.xml files, or as generated by the <literal>mvn
+         eclipse:eclipse</literal> command.
+      </para>
+      <para>
+         Your workspace should appear as follows:
+      </para>
       <programlisting><![CDATA[Web Beans
   jsr299-api
   webbeans-api
@@ -78,19 +101,20 @@
 CDI TCK
   jsr299-tck-api
   jsr299-tck-impl
-  parent
+  jsr299-tck-parent
 Web Beans JBoss TCK Runner
   webbeans-jboss-tck-runner
   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
+         developing tests. However, as you learned earlier, there are no references
          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.
+         webbeans-jboss-tck-runner (the project in the jboss-tck-runner
+         directory).
       </para>
       <para>
          Here are the steps to establish the link:
@@ -135,16 +159,19 @@
       </orderedlist>
       <para>
          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:
+         jsr299-tck-impl at runtime (so it can actually find the tests to
+         execute). But Eclipse doesn't distinguish between build-time and
+         runtime dependencies. As a result, we've created a circular dependency
+         between the projects. In all likelihood, Eclipse will struggle (if not
+         fail) to compile one or more projects. How can we break this cycle?
       </para>
+      <para>
+         As it turns out, the TCK runner doesn't need to access the tests to
+         build. It only needs its classes, configurations and other dependenices
+         at runtime (when the TestNG plugin executes). Therefore, we can remove
+         the TCK runner's dependence on the jsr299-tck-impl project by following
+         these steps:
+      </para>
       <orderedlist>
          <listitem>
             <para>
@@ -161,7 +188,6 @@
                Click on the Projects tab
             </para>
          </listitem>
-         a
          <listitem>
             <para>
                Select the TCK tests project (jsr299-tck-impl)
@@ -178,19 +204,22 @@
             </para>
          </listitem>
       </orderedlist>
+      <para>
+         You are now ready to execute an individual test class (or artifact).
+         Let's start with a test artifact capable of running in standalone mode.
+      </para>
    </section>
    <section>
       <title>Running a test in standalone mode</title>
       <para>
-         Your now ready to execute an individual test class (a class which
-         extends AbstractJSR299Test and is annotated with @Artifact). Select a
-         test class that is
-         <emphasis role="italic">not</emphasis>
-         annotated with
-         <literal>@IntegrationTest</literal>
-         and open it in the Eclipse editor. Right click in the editor view and
-         select TestNG &gt; Run as test. The TestNG view should pop out and you
-         should see all the tests pass (hopefully).
+         A standalone test artifact is a class which extends
+         <literal>AbstractJSR299Test</literal>, is annotated with
+         <literal>@Artifact</literal>, but is <emphasis
+         role="italic">not</emphasis> annotated with
+         <literal>@IntegrationTest</literal>. Select a standalone test artifact
+         and open it in the Eclipse editor.  Now right click in the editor view
+         and select Run As &gt; TestNG Test. The TestNG view should pop out and
+         you should see all the tests in that artifact pass (if all goes well).
       </para>
       <note>
          <para>
@@ -201,15 +230,16 @@
       </note>
       <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 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
-         execute an integration test. This will result in the artifact being
-         deployed to the container, which is JBoss AS 5.1 if you are using the
-         JBoss TCK runner.
+         sufficient to pass the TCK. The test must be executed using 
+         in-container mode. Using in-container mode is also the only way to
+         execute a test annotated with <literal>@IntegrationTest</literal>
+         (that's what the annotation means) as it requires container resources.
       </para>
+      <para>
+         Let's see what has to be done to execute an integration test. This
+         will result in the artifact being deployed to the container, which is
+         JBoss AS 5.1 if you are using the JBoss TCK runner.
+      </para>
    </section>
    <section id="eclipse-in-container">
       <title>Running integration tests</title>
@@ -228,15 +258,14 @@
       <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. 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
-         <literal>org.jboss.testharness.libraryDirectory</literal>
-         properties to point to the relative location of the related projects.
-         The properties should be defined as follows:
+         contains all of the necessary properties for in-container testing in
+         Eclipse. Assuming you followed the directory structure recommended in
+         <xref linkend="tck-environment"/>, you are good to go. Otherwise, you
+         may have to tune the
+         <literal>org.jboss.testharness.container.extraConfigurationDir</literal> and
+         <literal>org.jboss.testharness.libraryDirectory</literal> properties to
+         point to the relative location of the related projects. The properties
+         should be defined as follows:
       </para>
       <itemizedlist>
          <listitem>
@@ -266,23 +295,16 @@
 orjboss.testharness.container.forceRestart=false
 orjboss.testharness.runIntegrationTests=true</programlisting>
       <para>
-         You're
-         now ready to execute an integration test. Select an integration
-         test (a
-         class that extends
-         <literal>AbstractJSR299Test</literal>
-         and is annotated with both
-         <literal>@Artifact</literal>
-         and
-         <literal>@IntegrationTest</literal>
-         ) and open it in your Eclipse editor. Follow these steps to execute the
-         class with the TestNG plugin:
+         You're now ready to execute an integration test. Select an integration
+         test (a class that extends <literal>AbstractJSR299Test</literal> and is
+         annotated with both <literal>@Artifact</literal> and
+         <literal>@IntegrationTest</literal>) and open it in your Eclipse
+         editor. Follow these steps to execute the class with the TestNG plugin:
       </para>
       <orderedlist>
          <listitem>
             <para>
-               Right click in the editor view and select TestNG &gt; Run as
-               test
+               Right click in the editor view and select Run As &gt; TestNG Test
             </para>
          </listitem>
          <listitem>
@@ -357,7 +379,7 @@
          appropriately). 
       </para>
       <para>
-         You can simply right click and select TestNG &gt; Run as test for
+         You can simply right click and select Run As &gt; TestNG Test for
          all subsequent runs for the reason cited earlier, the run configuration
          for a class is retained indefinitely.
       </para>
@@ -406,8 +428,7 @@
          </listitem>
       </orderedlist>
       <para>
-         Now you don't have to do any special configuration for each test
-         class.
+         Now you don't have to do any special configuration per test class.
       </para>
       <para>
          You can stop the individual tests from running in-container by
@@ -420,4 +441,7 @@
          debug a test so that you can efficiently investigate test failures.
       </para>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/executing.xml
===================================================================
--- tck/trunk/doc/reference/en-US/executing.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/executing.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -3,11 +3,11 @@
 <chapter id="executing">
    <title>Executing the Test Suite</title>
    <para>
-      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.
+      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>
@@ -19,21 +19,26 @@
          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" />
+         Web Beans to use your CDI implementation as described in <xref
+         linkend="configuration" />.
       </para>
    </section>
 
    <section>
       <title>Running the Tests In Standalone Mode</title>
       <para>
-         To execute the TCK test suite against the Web Beans, first switch
-         to
-         the jboss-tck-runner directory in the extracted Web Beans
-         distribution:
+         To execute the TCK test suite against Web Beans, first switch to the
+         jboss-tck-runner directory in the extracted Web Beans distribution:
       </para>
 
       <programlisting>cd webbeans/jboss-tck-runner</programlisting>
+      <note>
+         <para>
+             These instructions assume you have extracted the CDI-related
+             software according to the recommendation given in <xref
+             linkend="tck-environment"/>.
+         </para>
+      </note>
       <para>
          Then execute the Maven 2 life cycle through the test phase:
       </para>
@@ -48,56 +53,49 @@
          SPI to invoke the test artifact within a mock Java EE life cycle and
          capture the results of the test. However, passing the suite in this
          mode is not sufficient to pass the TCK as a whole. The suite must be
-         passed while executing in in-container mode.
+         passed while executing using the in-container mode.
       </para>
    </section>
    <section>
       <title>Running the Tests In the Container</title>
       <para>
          To execute the test suite using in-container mode with the JBoss TCK
-         runner, you first have to setup JBoss AS as described in
-         <xref linkend="tck-in-jboss-as" />.
+         runner, you first have to setup JBoss AS as described in the 
+         <xref linkend="tck-in-jboss-as" /> callout.
       </para>
       <para>
-         Then, execute the TCK runner:
+         Then, execute the TCK runner with Maven 2 as follows:
       </para>
       <programlisting>mvn test -Dincontainer</programlisting>
       <para>
-         The presence of the
-         <literal>incontainer</literal>
-         property activates a Maven 2 profile that assigns the
-         <literal>org.jboss.testharness.standalone</literal>
-         system property to
-         <literal>false</literal>
-         and the
-         <literal>org.jboss.testharness.runIntegrationTests</literal>
-         system property to
-         <literal>true</literal>
-         , hence activating the in-container test mode. This time, all the test
-         artifacts in the test suite are executed.
+         The presence of the <literal>incontainer</literal> property activates a
+         Maven 2 profile that assigns the
+         <literal>org.jboss.testharness.standalone</literal> system property to
+         <literal>false</literal> and the
+         <literal>org.jboss.testharness.runIntegrationTests</literal> system
+         property to <literal>true</literal>, hence activating the in-container
+         test mode. This time, all the test artifacts in the test suite are
+         executed.
       </para>
       <para>
          The in-container profile will also start and stop the application
-         server automatically by setting the
-         <literal>org.jboss.testharness.container.forceRestart</literal>
-         to
+         server automatically, a feature which the profile activates by setting
+         the <literal>org.jboss.testharness.container.forceRestart</literal> to
          <literal>true</literal>.
       </para>
       <para>
-         The in-container mode uses the
-         <literal>Containers</literal>
-         SPI to deploy the test artifact to the container and execute the test
-         in a true Java EE life cycle. The JBoss TCK runner has a dependency on
-         the library that provides an implementation of this interface for JBoss
-         AS 5.1.
+         The in-container mode uses the <literal>Containers</literal> SPI to
+         deploy the test artifact to the container and execute the test in a
+         true Java EE life cycle. The JBoss TCK runner has a dependency on the
+         library that provides an implementation of this interface for JBoss AS
+         5.1.
       </para>
       <para>
-         Since in-container tests are executed in a remote JVM, the results
-         of
+         Since in-container tests are executed in a remote JVM, the results of
          the test must be communicated back to the runner over a
          container-supported protocol. The JBoss Test Harness provides
-         servlet-based communication over HTTP as described in
-         <xref linkend="incontainer-communication" />
+         servlet-based communication over HTTP as described in <xref
+         linkend="incontainer-communication" />.
       </para>
    </section>
    <section>
@@ -107,27 +105,28 @@
          in-container mode, each test class is packaged as a deployable artifact
          and deployed to the container. The test is then executed within the
          context of the deployed application. This leaves room for errors in
-         packaging. When investigating a test failure, it's helpful to be able
-         to inspect the artifact after it is generated. The TCK can accommodate
+         packaging. When investigating a test failure, you may find it helpful
+         to inspect the artifact after it's generated. The TCK can accommodate
          this type of inspection by "dumping" the generated artifact to disk.
       </para>
       <para>
-         This behavior is activated in the jboss-tck-runner project by appending
-         the
-         <literal>dumpArtifacts</literal>
-         command line property to the end of the command that invokes the Maven
-         test phase.
+         The feature just described is activated in the jboss-tck-runner project
+         by appending the <literal>dumpArtifacts</literal> command line property
+         to the end of the command that invokes the Maven 2 test phase.
       </para>
       <programlisting>mvn test-compile -DdumpArtifacts</programlisting>
       <para>
-         The output directory where the artifacts are written is configured to
-         dump the artifacts to the
-         <literal>target/jsr299-artifacts</literal>
-         directory.
+         The directory where the artifacts get written is configured using the
+         <literal>org.jboss.testharness.outputDirectory</literal> property. The
+         <literal>dumpArtifacts</literal> profile in the jboss-tck-runner
+         project sets this value to the relative directory path
+         <literal>target/jsr299-artifacts</literal>.
       </para>
       <para>
-         You can read more about this in
-         <xref linkend="dumping-test-artifacts" />.
+         You can read more about this feature in <xref linkend="dumping-test-artifacts" />.
       </para>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/installation.xml
===================================================================
--- tck/trunk/doc/reference/en-US/installation.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/installation.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -58,7 +58,7 @@
       </para>
    </section>
 
-   <section>
+   <section id="tck-environment">
       <title>The TCK Environment</title>
 
       <para>
@@ -259,4 +259,7 @@
          project.
       </para>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/introduction.xml
===================================================================
--- tck/trunk/doc/reference/en-US/introduction.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/introduction.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -296,4 +296,7 @@
          </para>
       </section>
    </section>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>

Modified: tck/trunk/doc/reference/en-US/master.xml
===================================================================
--- tck/trunk/doc/reference/en-US/master.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/master.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -6,4 +6,7 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-background.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-execution.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-test-harness.xml" />
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </book>

Modified: tck/trunk/doc/reference/en-US/part-background.xml
===================================================================
--- tck/trunk/doc/reference/en-US/part-background.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/part-background.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -24,4 +24,7 @@
    <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" />
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </part>

Modified: tck/trunk/doc/reference/en-US/part-execution.xml
===================================================================
--- tck/trunk/doc/reference/en-US/part-execution.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/part-execution.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -5,14 +5,17 @@
    <partintro>
       <para>
          In this part you learn how to execute the CDI TCK on the CDI
-         reference implementation (Web Beans). First, you are walked through the
-         steps necessary to execute the test suite on the Web Beans. Then you
-         discover how to modify the TCK runner to execute the test suite on your
-         own implementation. Finally, you learn how to debug tests from the test
-         suite in Eclipse.
+         reference implementation (Web Beans). First, you are walked through
+         the steps necessary to execute the test suite on Web Beans. Then you
+         discover how to modify the TCK runner to execute the test suite on
+         your own implementation. Finally, you learn how to debug tests from
+         the test suite in Eclipse.
       </para>
    </partintro>
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="executing.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="eclipse-running.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="eclipse-debugging.xml" />
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </part>

Modified: tck/trunk/doc/reference/en-US/part-test-harness.xml
===================================================================
--- tck/trunk/doc/reference/en-US/part-test-harness.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/part-test-harness.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -12,4 +12,7 @@
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/introduction.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/configuration.xml" />
    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/executing.xml" />
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </part>

Modified: tck/trunk/doc/reference/en-US/reporting.xml
===================================================================
--- tck/trunk/doc/reference/en-US/reporting.xml	2009-07-29 03:14:19 UTC (rev 3341)
+++ tck/trunk/doc/reference/en-US/reporting.xml	2009-07-29 04:40:05 UTC (rev 3342)
@@ -3,4 +3,7 @@
 <chapter id="reporting">
    <title>Reporting</title>
    <para>TODO</para>
+<!--
+vim: ts=3:sw=3:tw=80:set expandtab
+-->
 </chapter>




More information about the weld-commits mailing list