You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by mf...@apache.org on 2010/05/26 01:10:25 UTC
svn commit: r948246 [2/3] - in /myfaces/portlet-bridge/testsuite/trunk:
Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html TCK
Tests.html
Added: myfaces/portlet-bridge/testsuite/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html
URL: http://svn.apache.org/viewvc/myfaces/portlet-bridge/testsuite/trunk/Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html?rev=948246&view=auto
==============================================================================
--- myfaces/portlet-bridge/testsuite/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html (added)
+++ myfaces/portlet-bridge/testsuite/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html Tue May 25 23:10:25 2010
@@ -0,0 +1,1339 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html><head>
+<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"><title>Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide</title></head>
+<body><h1><a name="Table_of_Contents"></a>Table of Contents</h1><hr style="width: 100%; height: 2px;"><a href="#CopyrightLicense_Notice">Copyright/License Notice</a><br><a href="#Preface">Preface</a><br><a href="#Introduction_">Chapter 1: Introduction</a><br><a href="#Procedure_for_Portlet_1.0_Bridge_for">Chapter 2: Procedure for Portlet 1.0 Bridge for JavaServer™
+Faces 1.2 Certification</a><br><a href="#Requirements">Chapter 3: Requirements</a><br><a href="#Installation">Chapter 4: Installation</a><br><a href="#TCK_Project_Structure">Chapter 5: TCK Project Structure</a><br><a href="#Testing_a_Vendor_Implementation">Chapter 6: Testing a Vendor Implementation</a><br><a href="#Testing_a_Vendor_Implementation_in_a">Chapter 7: Testing a Vendor Implementation in a Pluto Environment</a><br><a href="#Verifying_the_Reference_Implementation">Chapter 8: Verifying the Reference Implementation in your Environment</a><br><a href="#TCK_Command_Reference">Chapter 9: TCK Command Reference</a><br><a href="#Debugging_Test_Problems">Chapter 10: Debugging Test Problems</a><br><a href="#Frequently_Asked_Questions">Appendix A: Frequently Asked Questions</a><br><br><br><br><br><br><h1><a name="CopyrightLicense_Notice"></a>Copyright/License Notice</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>Portlet 1.0 Bridge for JavaServer™ Faces 1.2<br>
+Compatibility Kit User’s Guide<br>
+For Technology Licensees<br>
+Version1.0<br>
+May 2010<br>
+<br>
+Copyright 2010 Apache Software Foundation<br>
+<br>
+Licensed 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<br>
+<br>
+http://www.apache.org/licenses/LICENSE-2.0<br>
+<br>
+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.<br>
+<br>[<a href="#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br>
+<br>
+<h1><a name="Preface"></a>Preface</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>This guide describes how to install, configure, and run the Technology
+Compatibility Kit (TCK) that provides tests for the Portlet
+1.0 Bridge for JavaServer™ Faces 1.2 (Bridge TCK). The Bridge TCK is
+designed as a portable, configurable automated test suite for verifying
+the compliance of a licensee’s implementation of the Portlet 1.0 Bridge
+for JavaServer™ Faces 1.2 Specification (hereafter referred to as a
+licensee implementation). It may also be used to verify that any
+compatible version of the bridge including the Reference Implementation
+runs correctly in a given JavaEE, Portlet container and Faces
+environment. The Bridge TCK runs as a Maven project located
+under Subversion source control in the Apache MyFaces
+PortletBridge project. It relies on JUnit and Selenium to
+provide the necessary test harness and reporting tools to run
+the test suite.<br>
+<br>
+<h2>Who Should Use This Book</h2>
+This guide is for licensees of Oracle Corporation's Portlet 1.0 Bridge
+for JavaServer™ Faces 1.2 technology to assist them in running the test
+suite that verifies compliance of their<br>
+implementation of the Portlet 1.0 Bridge for JavaServer™ Faces
+1.2 Specification.<br>
+<br>
+<div style="margin-left: 40px;">NOTE All references to
+specific Web URLs are given for your convenience in locating the
+resources quickly. These references are always subject to changes that
+are in many cases beyond the control of the authors of this guide.<br>
+</div>
+<br>
+<h2>Before You Read This Book</h2>
+Before reading this guide, you should familiarize yourself with the
+Java programming language, Portlet 1.0 standard (JSR 168),
+ JavaServer Faces 1.2 standard (JSR 252)
+and the Portlet 1.0 Bridge for JavaServer™ Faces 1.2 Specification (
+JSR 301). The Bridge TCK 1.0 is based on the JSR 301 Specification.
+Links to the specification and other product information can be found
+on the Web at: http://www.jcp.org/en/jsr/detail?id=301<br>
+<br>
+<h2>How This Book Is Organized</h2>
+If you are installing and using the Bridge TCK for the first time, it
+is recommended that you read chapters 1, 2, and 3 completely for the
+necessary background information, and then perform the steps outlined
+in chapters 4, 5 or 6, and 7, while referring to chapters 8, 9, 10, and
+the appendix as necessary.<br>
+<br>
+Chapter 1, “<a href="#Introduction_">Introduction</a>,” gives an overview of the principles that
+apply generally to all Technology Compatibility Kits (TCKs) and
+describes the Bridge TCK. It also<br>
+includes a listing of the basic steps needed to get up and running with
+the Bridge TCK.<br>
+<br>
+Chapter 2, “<a href="#Procedure_for_Portlet_1.0_Bridge_for">Procedure for Portlet 1.0 Bridge for JavaServer<sup>tm</sup> Faces 1.2 Certification</a>,” describes the
+conformance testing procedure and testing requirements.<br>
+<br>
+Chapter 3, “<a href="#Requirements">Requirements</a>,” lists the hardware and software requirements
+that must be met before the Bridge Compatibility Test Suite can be run.<br>
+<br>
+Chapter 4, “<a href="#Installation">Installation</a>,” explains how to install Bridge TCK on
+machines that run the Solaris, Linux, and Windows XP/2000 operating
+systems.<br>
+<br>
+Chapter 5, “<a href="#TCK_Project_Structure">TCK Project Structure</a>,”
+explains how the TCK is organized in its various directories.<br>
+<br>
+Chapter 6, “<a href="#Testing_a_Vendor_Implementation">Testing a Vendor Implementation</a>,”
+explains how to setup and run test suite using your bridge implementation in your non-Pluto based test server.<br>
+<br>
+Chapter 7, “<a href="#Testing_a_Vendor_Implementation_in_a">Testing a Vendor Implementation in a Pluto Environment</a>,” explains how to setup and run test suite using your bridge implementation in a Pluto based test server.<br>
+<br>
+Chapter 8, “<a href="#Verifying_the_Reference_Implementation">Verifying the Reference Implementation in your Environment</a>,” explains how to setup and run test suite using bridge reference implementation in your non-Pluto based test server<br><br>Chapter 9, "<a href="#TCK_Command_Reference">TCK Command Reference</a>," lists each of the properties which can be set to control the behavior of a particular test run.<br>
+<br>
+Chapter 10, “<a href="#Debugging_Test_Problems">Debugging Test Problems</a>,” describes several approaches for
+dealing with tests that fail to execute properly.<br>
+<br>Appendix A, “<a href="#Frequently_Asked_Questions">Frequently Asked Questions</a>,” provides answers to
+frequently asked questions.<br><br>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br>
+<br>
+<h2>Chapter 1 </h2><h1><a name="Introduction_"></a>Introduction </h1><hr style="width: 100%; height: 2px;"><br><br><br> <br>
+
+This chapter provides an overview of the principles that apply
+generally to all Technology Compatibility Kits (TCKs) and describes the
+Portlet 1.0 Bridge for JavaServer™ Faces 1.2<br>
+Compatibility Kit (Bridge TCK). It also includes a listing of what is
+needed to get up and running with the Bridge TCK.<br>
+<h2>Compatibility Testing</h2>
+Compatibility testing differs from traditional product testing in a
+number of ways. The focus of compatibility testing is to test those
+features and areas of an implementation that are likely to differ
+across implementations. It attempts to ensure that users of
+any given implementation will receive the same results regardless of
+the underlying implementation strategy. Compatibility test development
+for a given feature relies on a complete specification and reference
+implementation for that feature. Compatibility testing is not primarily
+concerned with robustness, performance, or ease of use.<br>
+<br>
+<h2>Why Compatibility Testing is Important</h2>
+Java™ platform compatibility is important to different groups involved
+with Java technologies for different reasons:<br>
+<ul>
+<li>Compatibility testing is the means by which Sun
+Microsystems ensures that the Java platform does not become fragmented
+as it is ported to different operating systems and hardware
+environments.</li>
+<li>Compatibility testing benefits developers working in the
+Java programming language, allowing them to write applications once and
+then to deploy them across heterogeneous computing environments without
+porting.</li>
+<li>Compatibility testing allows application users to obtain
+applications from disparate sources and deploy them with confidence.</li>
+<li>Compatibility testing benefits Java platform implementors
+by ensuring a level playing field for all Java platform ports.</li>
+</ul>
+<h2>TCK Compatibility Rules</h2>
+Compatibility criteria for all technology implementations are embodied
+in the TCK Compatibility Rules that apply to a specified technology.
+Each TCK tests for adherence to these Rules as described in Chapter 2,
+“Procedure for Portlet 1.0 Bridge for JavaServer™ Faces 1.2
+Certification.”<br>
+<br>
+<h2>TCK Overview</h2>
+A TCK is a set of tools and tests used to verify that a licensee’s
+implementation of Oracle Corporation's Portlet 1.0 Bridge for
+JavaServer™ Faces 1.2 technology conforms to the applicable<br>
+specification. All tests in the TCK are based on the written
+specifications for the Java platform. Compatibility testing is a means
+of ensuring correctness, completeness, and consistency across all
+implementations. The set of tests included with each TCK is called the
+“test suite.” All tests in the Bridge TCK’s test suite are
+self-checking and do not require tester interaction. Most<br>
+tests return either a Pass or Fail status. For a given licensee’s
+implementation to be certified, all of the required tests must pass.
+The definition of required tests will change over time. Before your
+final<br>
+certification test pass, be sure to download the latest Excludes File
+for the TCK you are using from the TCK site
+(http://wiki.apache.org/myfaces/PortletBridge). <br>
+<br>
+<h2>Java Community Process (JCP) Program and Compatibility Testing</h2>
+The Java Community Process(SM) (JCP(SM)) program is the formalization
+of the open process that Sun Microsystems, Inc. has been using since
+1995 to develop and<br>
+revise Java technology specifications in cooperation with the
+international Java community. The JCP program specifies that the
+following three major components must be included as deliverables in a
+final Java technology release under the direction of the responsible
+Expert Group:<br>
+<ul>
+<li>Technology Specification</li>
+<li>Reference Implementation</li>
+<li>Technology Compatibility Kit (TCK)</li>
+</ul>
+For further information on the JCP program see this URL:
+http://www.jcp.org.<br>
+<br>
+<h2>The Bridge TCK</h2>
+The Bridge TCK 1.0 is designed as a portable, configurable, automated
+test suite for verifying the compliance of a licensee’s implementation
+with Oracle Corporation's<br>
+Portlet 1.0 Bridge for JavaServer™ Faces 1.2 specification.<br>
+<br>
+<h2>Bridge TCK Specifications and Requirements</h2>
+This section lists the applicable requirements and specifications.<br>
+• Specification Requirements – Software requirements for a Bridge<br>
+implementation are described in detail in the Portlet 1.0
+Bridge for JavaServer™ Faces 1.2 Specification.<br>
+Links to the JSR 301 specification and other product information can be
+found at http://www.jcp.org/en/jsr/detail?id=301.<br>
+• Reference Implementation – The designated Reference Implementation for<br>
+conformance testing of implementations based upon JSR 301 Specification<br>
+is Apache Open Source Project, MyFaces Portlet Bridge 1.0
+(http://myfaces.apache.org/portlet-bridge/1.0/index.html).<br>
+<br>
+<h2>The Bridge TCK</h2>
+The Bridge TCK is composed of :<br>
+<ul>
+<li>a teststuite, which is a collection of tests and
+supplemental files that provide data for the automatic running of tests
+through the test harness.</li>
+<li>an exclude list, which provides a list of tests that your
+implementation is not required to pass.</li>
+<li>TCK documentation.</li>
+<li>a set of maven .pom files providing the necessary
+instructions for building the test stuite for your test environment and
+running the test harness to verify your environment.</li>
+</ul>
+The Bridge TCK 1.0 is a maven project maintained in Subversion source
+control as part of the Apache MyFaces Portlet Bridge project.
+ The TCK test stuite is built and run using maven commands.
+ The test harness, used to automate executing the TCK tests
+uses JUnit and Selenium. Maven automatically accesses the
+necessary versions and runs them during the appropriate phase of the
+lifecycle. More information can be found on the web:<br>
+<ul>
+<li>Maven: consult the Apache Maven website
+(http://maven.apache.org/).</li>
+<li>Subversion: consult the Apache Subversion website
+(http://subversion.apache.org/).</li>
+<li>JUnit: consult the JUnit website (http://www.junit.org/).</li>
+<li>Selenium: consult the Selenium website
+(http://seleniumhq.org/)</li>
+</ul>
+<br>
+<h3><a name="Typical_Usage"></a>Typical Usage</h3>
+Each TCK test is implemented in its own specific portlet built from the
+test suite source. Most test portlets are grouped into a
+single portlet application. However, because one test
+involves varying values in the application's web.xml, the entire test
+suite is comprised of two portlet applications: a main
+testsuite portlet application containing most of the test portlets, and
+an additional testsuite portlet application containing an individual
+test portlet with a distinct (web.xml) configuration. Each of
+these test suite portlet applications is built using a maven command.
+ As described in detail later, the command used to generate
+the war files includes flexibility for:<br>
+<ul>
+<li>packaging a specific Faces 1.2 implementation type
+and version (e.g. Mojarra or MyFaces) into the war. This is
+used in situations where your application server isn't a fully
+compliant JavaEE 5 server (i.e. one that includes Faces 1.2)</li>
+<li>packaging your bridge implementaion into the war.
+ This is used if your bridge isn't already deployed for use in
+the application server as part of the portal/portlet container
+deployment.</li>
+<li>including a proper deployment descriptor for deploying the
+applications in a pluto 1.0 or pluto 2.0 environment.</li>
+</ul>
+Once generated, the testsuite wars are deployed to the host application
+server. The test server(s) must not only contain a Portlet
+1.0 (compatible) container to host the portlet application but must
+also include a technology for accessing and executing each portlet in
+these applications by URL. Typically, this involves a portal
+application hosting a set of portal pages where each page contains a
+distinct test portlet. <br>
+<br>
+<div style="margin-left: 40px;">Note: The test
+harness requires a distinct URL to execute each test. In most
+cases this translates into placing each test portlet on a distinct page.</div>
+<br>
+Once the test applications are deployed and made accesible by URL, the
+TCK is executed by running a second maven command. This
+command reads a test file containing the test URLs (provided by you)
+and executes each test in the file via the JUnit/Selenium harness.
+ Upon completion a report is generated providing summary and
+detailed information of the test results.<br>
+<br>
+<div style="margin-left: 40px;">Note: Prior to
+running the automated test harness you are encouraged to verify your
+portal/test suite configuration by invoking some of the test pages
+directly from a browser. Thes tests are designed to ouput
+valid HTML indicating the test status along with the internal tags used
+by the harness.</div>
+<h3>TCK Compatibility Test Suite</h3>
+The test suite is the collection of tests used by the test harness to
+test the compliance of a given Bridge in a given runtime environment.
+The tests are designed to verify that a licensee’s implementation of
+the technology complies with the appropriate specification. The
+individual tests correspond to assertions of the specification. The
+descriptions of tests that make up the TCK compatibility test suite are<br>included in the projects root directory in a file called "TCK Tests.html". <br>
+<br>
+The Bridge TCK 1.0 test suite comprises two test categories:<br>
+<ul>
+<li>A signature test that checks that the public APIs
+are supported in the implementation that is being tested.</li>
+<li>Functional tests that check for behavior correctness for
+all the (testable) assertations in the specification .</li>
+</ul>
+<h3>Exclude Lists</h3>
+Each version of a TCK includes an Exclude List file. This file
+identifies tests which do not have to be run as their results may not
+be repeatable in all environments. Whenever tests are run, the test
+harness automatically excludes any test on the Exclude List from being
+executed.<br>
+<br>
+A licensee is not required to pass any test—or even run any test—on the
+Exclude List. However, as many of these tests are excluded
+because of specific environmental limitations, licensee's are
+encouraged to review the comments in the excluded file to determine if
+the test can be successfully run in he or her environment, and if so,
+to include the test to verify proper behavior. <br>
+<br>
+<br>
+<div style="margin-left: 40px;">Note: Licensees are not
+permitted to alter or modify the Exclude Lists. Changes to an
+Exclude List can only be made by using the procedure described in
+“Portlet Test Appeals Process”.<br></div>
+<br>
+<h2>Bridge TCK—Getting Started</h2>
+This section provides a general overview of what needs to be done to
+install, set up, test, and use the Bridge TCK:<br>
+<ol>
+<li>Make sure that the following software has been correctly
+installed:<br>
+<ul>
+<li>Sun Microsystems JDK software version 1.5.x
+on the system you
+are accessing the TCK subversion repository from and from which you
+will build the tests and run the harness.</li>
+<li>The latest version of Subversion
+(http://subversion.apache.org/packages.html). If you are
+running on Windows you may prefer to use the tortoiseSVN subversion
+window shell (http://tortoisesvn.net/downloads)</li>
+<li>The latest version of Maven
+(http://maven.apache.org/download.html)</li>
+<li>An application server containing a portal/Java Portlet
+1.0 (compatible) portlet container.<br>
+</li>
+</ul>
+Note: Consult the documentation for each of these software applications
+for installation instructions.<br>
+</li>
+<li>Install the TCK 1.0 software. <br>
+<ul>
+<li>Create a directory to contain the TCK project</li>
+<li>Use the subversion checkout command to checkout the TCK
+from <font size="3"> <a href="http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0">http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0</a></font>.</li>
+</ul>
+</li>
+<li>Build the TCK portlet applications using Maven.</li>
+<li>Deploy the generated applications to your application
+server.</li>
+<li>Construct individual test pages, one for each test, using
+the installed portal.</li>
+<li>Verify the test pages/tests by manually accessing a few
+pages.</li>
+<li>Generate a test.xml test file containing the URLs used to
+access each test.</li>
+<li>(Optionally) generate a login.properties file containing
+the authentication name/password the harness passes to the portal when
+challenged.</li>
+<li>Run the TCK test harness by issuing the appropriate maven
+command.</li>
+<li>Review the results.</li>
+<li>Debug problems, fix and retry above until all tests pass.</li>
+</ol>
+[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><br><br>
+<h2>Chapter 2</h2>
+<h1><a name="Procedure_for_Portlet_1.0_Bridge_for"></a>Procedure for Portlet 1.0 Bridge for JavaServer™
+Faces 1.2 Certification</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>This chapter describes the compatibility testing procedure and
+compatibility requirements for Portlet 1.0 Bridge for JavaServer™ Faces
+1.2 certification.<br>
+<br>
+<h3>Certification Overview</h3>
+<ul>
+<li>Install the appropriate version of the Technology
+Compatibility Kit (TCK) and execute it in accordance with the
+instructions in this User’s Guide.</li>
+<li>Ensure that you meet the requirements outlined in
+“Compatibility Requirements” below.</li>
+<li>Certify to Java Partner Engineering that you have finished
+testing and that you meet all the compatibility requirements.</li>
+</ul>
+<h3>Compatibility Requirements</h3>
+<h4>Definitions</h4>
+These definitions are for use only with these compatibility
+requirements and are not intended for any other purpose.<br>
+<br>
+<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2">
+<tbody>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Term</td>
+<td>Definition</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Computational
+Resource</td>
+<td>A piece of hardware or software that may vary in
+quantity, existence, or version, which may be required to exist in a
+minimum quantity and/or at a specific or minimum revision level so as
+to satisfy the requirements of the Test Suite. Examples of
+computational resources that may vary in quantity are RAM and file
+descriptors. Examples of computational resources that may vary in
+existence (this is, may exist or not) are graphics cards and device
+drivers. Examples of computational resources that may vary in version
+are operating systems and device drivers.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Conformance
+Tests</td>
+<td>All tests in the Test Suite for an indicated Technology
+Under Test, as distributed by the Maintenance Lead, excluding those
+tests on the Exclude List for the Technology Under Test.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Container</td>
+<td>An implementation of the associated Libraries, as
+specified in the Specifications, and a version of a J2SE Runtime
+Product, as specified in the Specifications, or a later version of a
+J2SE Runtime Product that also meets these compatibility requirements.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Documented</td>
+<td>Made technically accessible and made known to users,
+typically by means such as marketing materials, product documentation,
+usage messages, or developer support programs.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Exclude
+List</td>
+<td> The most current list of tests, distributed
+by the Maintenance Lead, that are not required to be passed to certify
+conformance. The Maintenance Lead may add to the Exclude List for that
+Test Suite as needed at any time, in which case the updated Exclude
+List supplants any previous Exclude Lists for that Test Suite.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Libraries</td>
+<td>The class libraries, as specified through the Java
+Community Process<sup>SM</sup> (JCP<sup>SM</sup>),
+for the Technology Under Test.<br>
+<br>
+The Libraries for Portlet 1.0 Bridge are listed at the end of this
+chapter.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Location
+Resource</td>
+<td>A location of classes or native libraries that are
+components of the test tools or tests, such that these classes or
+libraries may be required to exist in a certain location in order to
+satisfy the requirements of the test suite. For example, classes may be
+required to exist in directories named in a CLASSPATH variable, or
+native libraries may be required to exist in directories named in a
+PATH variable.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Maintenance
+Lead</td>
+<td>The JCP member responsible for maintaining the
+Specification, reference implementation, and TCK for the Technology.
+Oracle Corportation is the Maintenance Leads for Portlet Bridge 1.0.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Operating
+Mode</td>
+<td>Any Documented option of a Product that can be changed
+by a user in order to modify the behavior of the Product. For example,
+an Operating Mode of a Runtime can be binary (enable/disable
+optimization), an enumeration (select from a list of localizations), or
+a range (set the initial Runtime heap size). </td>
+</tr>
+<tr>
+<td>Product</td>
+<td>A licensee product in which the Technology Under Test
+is implemented or
+incorporated, and that is subject to compatibility testing.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Product
+Configuration</td>
+<td>A specific setting or instantiation of an Operating
+Mode.<br>
+<br>
+For example, a Runtime supporting an Operating Mode that permits
+selection of an initial heap size might have a Product Configuration
+that sets the initial heap size to 1 Mb.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Resource</td>
+<td>A Computational Resource, a Location Resource, or a
+Security Resource. </td>
+</tr>
+<tr>
+<td>Rules</td>
+<td>These definitions and rules in this Compatibility
+Requirements section of this User’s Guide.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Runtime</td>
+<td>The Containers specified in the Specifications.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Security
+Resource</td>
+<td>A security privilege or policy necessary for the proper
+execution of the Test Suite.<br>
+<br>
+For example, the user executing the Test Suite will need the privilege
+to access the files and network resources necessary for use of the
+Product.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Specifications</td>
+<td>The documents produced through the JCP that define a
+particular Version of a Technology.<br>
+<br>
+The Specifications for the Technology Under Test can be found later in
+this chapter.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Technology</td>
+<td>Specifications and a reference implementation produced
+through the JCP.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Technology
+Under Test</td>
+<td>Specifications and the reference implementation for
+Portlet 1.0.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Test
+Suite</td>
+<td>The requirements, tests, and testing tools distributed
+by the Maintenance Lead as applicable to a given Version of the
+Technology.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">Version</td>
+<td>A release of the Technology, as produced through the
+JCP.</td>
+</tr>
+</tbody>
+</table>
+<br>
+ <br>
+<br>
+<h4> Rules for Bridge Products</h4>
+<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2">
+<tbody>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT1</td>
+<td style="vertical-align: top;">The Product must be
+able to satisfy all applicable compatibility
+requirements, including passing all Conformance Tests, in every Product
+Configuration and in every combination of Product Configurations,
+except only as specifically exempted by these Rules.<br>
+<br>
+For
+example, if a Product provides distinct Operating Modes to optimize
+performance, then that Product must satisfy all applicable
+compatibility requirements for a Product in each Product Configuration,
+and combination of Product Configurations, of those Operating Modes.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT1.1</td>
+<td style="vertical-align: top;">If an Operating
+Mode controls a Resource necessary for the basic execution of the Test
+Suite, testing may always use a Product Configuration of that Operating
+Mode providing that Resource, even if other Product Configurations do
+not provide that Resource. Notwithstanding such exceptions, each
+Product must have at least one set of Product Configurations of such
+Operating Modes that is able to pass all the Conformance Tests.<br>
+<br>
+For example, a Product with an Operating Mode that controls a security
+policy (i.e., Security Resource) which has one or more Product
+Configurations that cause Conformance Tests to fail may be tested using
+a Product Configuration that allows all Conformance Tests to pass.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT1.2</td>
+<td style="vertical-align: top;">A Product
+Configuration of an Operating Mode that causes the Product to report
+only version, usage, or diagnostic information is exempted from these
+compatibility rules.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT2</td>
+<td style="vertical-align: top;">Some Conformance
+Tests may have properties that may be changed (currently there are no
+such tests in this TCK). Apart from changing such properties and other
+allowed modifications described in this User’s Guide, no source or
+binary code for a Conformance Test may be altered in any way without
+prior written permission. Any such allowed alterations to the
+Conformance Tests would be posted to the Java Partner Engineering web
+site and apply to all licensees.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT3</td>
+<td style="vertical-align: top;">The testing tools
+supplied as part of the Test Suite or as updated by the Maintenance
+Lead must be used to certify compliance.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT4</td>
+<td style="vertical-align: top;">The Exclude List
+associated with the Test Suite cannot be modified.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT5</td>
+<td style="vertical-align: top;">The Maintenance
+Lead can define exceptions to these Rules. Such exceptions would be
+made available to and apply to all licensees.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT6</td>
+<td style="vertical-align: top;">All hardware and
+software component additions, deletions, and modifications to a
+Documented supporting hardware/software platform, that are not part of
+the Product but required for the Product to satisfy the compatibility
+requirements, must be Documented and available to users of the Product.<br>
+<br>
+For example, if a patch to a particular version of a supporting
+operating system is required for the Product to pass the Conformance
+Tests, that patch must be Documented and available to users of the
+Product.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT7</td>
+<td style="vertical-align: top;">The Product must
+contain the full set of public and protected classes and interfaces for
+all the Libraries. Those classes and interfaces must contain exactly
+the set of public and protected methods, constructors, and fields
+defined in the Specifications for those Libraries. No subsetting,
+supersetting, or modifications of the public and protected API of the
+Libraries are allowed except only as specifically exempted by these
+Rules.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT7.1</td>
+<td style="vertical-align: top;">If a Product
+includes Technologies in addition to the Technology Under Test, then it
+must contain the full set of combined public and protected classes and
+interfaces. The API of the Product must contain the union of the
+included Technologies. No further subsetting, supersetting, or
+modifications to the APIs of the included Technologies are allowed.</td>
+</tr>
+<tr>
+<td style="vertical-align: top; white-space: nowrap;">PLT8</td>
+<td style="vertical-align: top;">The functional
+programmatic behavior of any binary class or interface must be that
+defined by the Specifications.</td>
+</tr>
+</tbody>
+</table>
+<br>
+<h2>Portlet Test Appeals Process</h2>
+Oracle Corportation has a well established process for managing
+challenges to its Portlet 1.0 Bridge Test Suite and plans to continue using a similar process in the future.
+Oracle Corporation, as Maintenance Lead, will authorize representatives from its engineering
+team to be the point of contact for all test challenges.<br>
+<br>
+<h3>Process Used to Manage Challenges to Bridge Tests:</h3>
+The following process will be used to manage challenges to Portlet 1.0
+Bridge tests:
+<ol>
+<li>Who can make challenges to the Portlet 1.0
+Bridge tests?<br><br>
+Only licensees of the Portlet 1.0
+Bridge TCK.<br><br></li>
+<li>What challenges to the Portlet 1.0
+Bridge tests may be submitted?<br><br>
+Individual (or related) tests may be challenged for reasons such as:<br>
+<ul>
+<li>Test is buggy (i.e., program logic errors).</li>
+<li>Specification item covered by the test is ambiguous.</li>
+<li>Test does not match the specification.</li>
+<li>Test assumes unreasonable hardware and/or software
+requirements.<br><br></li>
+</ul>
+</li>
+
+
+<li>How are challenges submitted?<br><br>To the public comment list for JSR 301 (jsr-301-public@jcp.org).<br>Appeals must be in writing as described in the Test
+Challenge form below.<br><br></li>
+
+
+
+<li>How and by whom are challenges addressed?<br><br>The Oracle engineer who is the contact point coordinates the review and
+decisions made by test development and specification development engineers.
+<br><br>See the Portlet 1.0 Bridge TCK Test Appeals Steps below.<br><br></li>
+
+
+
+
+
+
+<li>How are approved changes to the Portlet 1.0
+Bridge tests
+managed?<br><br>All
+tests found to be invalid are placed on the Exclude
+List for that version of the Portlet 1.0 Bridge TCK within 1 business day. An
+announcement is sent to the jsr-301-public@jcp.org describing the
+change and where/how to acquire it.<br><br>Oracle as Maintenance Lead, has the option of creating an alternative
+test to address any challenge. Alternative tests (and criteria for their use)
+will be updated in the SVN source repository. Note that passing an
+alternative test is deemed equivalent with passing the original test.</li>
+</ol><h3>
+Portlet TCK Test Appeals Steps</h3><ol><li>
+Portlet licensee writes a test challenge to the Maintenance Lead
+contesting the validity of one or a related set of Portlet tests.<br><br>A
+detailed justification for why each test should be invalidated must be
+included with the challenge as described by the Test Challenge form
+below.<br><br></li><li>The Maintenance Lead evaluates the challenge.<br><br>If the appeal is incomplete or unclear, it is returned to the
+submitting licensee for correction. If all is in order, the Maintenance Lead will check
+with the test developers to review the purpose and validity of the test before
+writing a response. The Maintenance Lead will attempt to complete the response
+within 5 business days. If the challenge is similar to a previously rejected
+test challenge (i.e., same test and justification), the Maintenance Lead
+will send the previous response to the licensee.<br><br></li><li>
+The challenge and any supporting materials from test developers is
+sent to the specification engineers for evaluation.<br><br>A decision of test validity or invalidity is normally made within 15
+working days of receipt of the challenge. All decisions will be documented with
+an explanation of why test validity was maintained or rejected.<br><br></li><li>
+The licensee is informed of the decision and proceeds accordingly.<br><br>If the test challenge is approved and one or more tests are
+invalidated, the Maintenance Lead places the tests on the Exclude List for that version
+of the Portlet (effectively removing the test(s) from the Test Suite). All
+tests placed on the Exclude List will have a JIRA bug report written to document the
+decision and made available to all through the JIRA bug reporting database on
+the Apache web site. If the test is valid but difficult to
+pass due to hardware or operating system limitations, the Maintenance Lead may
+choose to provide an alternate test to use in place of the original test (all
+alternate tests are made available to the licensee community).<br><br></li><li>
+If the test challenge is rejected, the licensee may choose to
+escalate the decision to the Executive Committee (EC), however, it is expected that the
+licensee would continue to work with the Maintenance Lead to resolve the issue
+and only involve the EC as a last resort.</li></ol><br><br><h4>Test Challenge Form</h4>Replace the values in [] with an appropriate response:<br><div style="margin-left: 40px;">[<span style="font-weight: bold;">Test Challenger Name and Company</span>]<br>[<span style="font-weight: bold;">Specification Name(s) and Version(s)</span>]<br>[<span style="font-weight: bold;">Test Suite Name and Version</span>]<br>[<span style="font-weight: bold;">Exclude List Version</span>]<br>[<span style="font-weight: bold;">Test Name</span>]<br>[<span style="font-weight: bold;">Complaint</span> (argument for why test is invalid)]<br></div><br><br><h4>Test Challenge Response Form</h4><div style="margin-left: 40px;">[<span style="font-weight: bold;">Test Defender Name and Company</span>]<br>[<span style="font-weight: bold;">Test Defender Role in Defense</span> (e.g., test developer, Maintenance
+Lead, etc.)]<br>[<span style="font-weight: bold;">Specification Name(s) and Version(s)</span>]<br>[<span style="font-weight: bold;">Test Suite Name and Version</span>]<br>[<span style="font-weight: bold;">Test Name</span>]<br>[<span style="font-weight: bold;">Defense</span> (argument for why test is valid)]<br>
+[<span style="font-weight: bold;">Implications of test invalidity</span>
+(e.g., other affected tests and test framework code, creation or
+exposure of ambiguities in spec (due to unspecified requirements),
+invalidation of the reference implementation, creation of serious holes
+in test suite)]<br>[<span style="font-weight: bold;">Alternatives</span> (e.g., are alternate test appropriate?)]<br></div><br><h2>
+Reference Implementation for Portlet 1.0 Bridge</h2>The Designated Reference Implementation for compatibility testing of
+Portlet 1.0 Bridge is as follows:<br><ul><li>
+Reference Implementation done as an Apache Open Source Project, MyFaces PortletBridge
+1.0</li><li>
+Java™ 2 Platform, Standard Edition (J2SE™) Versions 1.5.x</li><li>
+Redhat Linux 7.2, Solaris™ Operating System V 8 and 9/SPARC, and Microsoft Windows 2000 and XP.<br></li></ul><h2>
+Specification for Portlet 1.0 Bridge for JavaServer<sup>TM</sup> Faces 1.2</h2>
+The following web sites contain the Specifications for Portlet
+1.0 Bridge for JavaServer<sup>TM</sup> Faces 1.2:<br><div style="margin-left: 40px;">
+http://www.jcp.org/en/jsr/detail?id=301<br></div><br><h2>Libraries for Portlet 1.0 Bridge for JavaServer<sup>TM</sup> Faces 1.2</h2>
+The following packages constitute the required class libraries for
+Java™ Portlet 1.0:<br><ul><li>javax.portlet.faces</li><li>javax.portlet.faces.annotation</li><li>javax.portlet.faces.component</li><li>javax.portlet.faces.preference</li></ul>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><h2>
+Chapter 3</h2><h1><a name="Requirements"></a>
+Requirements</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>This chapter lists the required hardware configurations and
+prerequisite software that must be present before you can run the Bridge TCK.<br><br><h2>
+Hardware Requirements</h2>
+You can run the Portlet TCK software on compatible Java™ platforms on
+both Sun workstations and on personal computers. The following section
+lists the
+hardware requirements for both the TCK and the reference
+implementation. Hardware requirements for other implementations will
+vary.<br><br>All systems must meet the following recommended and minimum hardware requirements:<br><ul><li>
+CPU running at 500 MHz minimum</li><li>
+512MB of RAM minimum</li><li>
+1024MB of swap space minimum</li><li>
+512 MB of free disk space minimum for writing data to log files</li><li>Network access</li></ul><br><h2>
+Software Requirements</h2>The Bridge TCK Testharness relies on Selenium Remote Control to execute the tests/process the results. Click <a href="http://seleniumhq.org/about/platforms.html#browsers">here for the specific OS/browser matrix supported by Selenium</a>. In summary, you can access run the Bridge TCK software on Sun Solaris™ operating system,
+Linux, and Windows XP/2000 platforms that meet the following minimum software requirements:<br><div style="margin-left: 40px;">
+Operating Systems:<br><ul><li>Sun Solaris V 8 and 9</li><li>Microsoft Windows 2000 Professional or Microsoft Windows XP Pro</li><li>Redhat Linux 7.1</li></ul></div><div style="margin-left: 40px;">Browsers:<br><ul><li>Mozilla Firefox 2/3 (default referenced by the maven scripts)</li><li>IE 7/8</li><li>Opera 8/9</li><li>Safari 2/3</li></ul></div><br>In addition to build and run the TCK you must have the following Java<small><sup>TM</sup></small> software installed:<br><ul><li>JavaEE™ 5 Platform, JDK: Version 1.5 (any)</li><li>Vendors application server of choice with the minimum requirement that the application server contain a Servlet container.</li><li>Java<small><sup>TM</sup></small> Portlet 1.0 (compatible) platform software, such as a vendor’s implementation</li><li>JavaServer<small><sup>TM</sup></small> Faces 1.2 platform software
+(if not already included in the application server). If using
+Mojarra: Version 1.2_03 or later. If using MyFaces: Version 1.2.2
+or later</li><li>Java<small><sup>TM</sup></small> consumer application which can host/expose test portlets in individually addressable URL resources (such as a portal)</li></ul>Finally, as the TCK is built in run within a local version of the Apache project, you will need to install:<br><ul><li>Apache Maven</li><li>Apache Subversion (or equivalent such as TortoiseSVN)</li></ul>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><h2>Chapter 4</h2><h1><a name="Installation"></a>
+Installation</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>This chapter explains how to install the Bridge TCK on a system
+running the Sun Solaris™, Redhat Linux, or Microsoft Windows operating system. <br><br><h2>Obtaining the needed TCK Software</h2>Obtain needed software from:<br><ul><li>Apache Maven: <a href="http://maven.apache.org/download.html">http://maven.apache.org/download.html</a></li><li>Apache Subversion: <a href="http://subversion.apache.org/packages.html">http://subversion.apache.org/packages.html</a> or TortoiseSVN: <a href="http://tortoisesvn.net/downloads">http://tortoisesvn.net/downloads</a></li><li>Bridge TCK 1.0: Checkout project source using subversion from <br><font size="3"><a href="http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0">http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0</a></font> </li><li>Bridge 1.0 Reference Implementation (if needed for reference/use):<br><a href="http://myfaces.apache.org/portlet-bridge/download.html">http://myfaces.apache.org/portlet-bridge/download.html</a></l
i></ul><br><br><h2>
+Installing the Software</h2><ol><li>
+Install the JavaEE™ 5 Platform, JDK: Version 1.5 (any)<br>
+Download the JavaEE™ 5 Platform, JDK software from the Java Software web
+site and install. See the installation instructions that accompany the
+software for additional information.</li><li>Install Maven</li><li>Install Subversion</li><li>Install an application server. </li><li>Install a Portlet 1.0-compliant portlet container, such as the
+reference
+implementation done as an Apache Open Source Project, Pluto 1.0 or Pluto 2.0.<br>If
+the portlet container software doesn't come configured with consumer
+portal software that is used as the application that exposes portlets
+via page (resource) URLs, then also install such consumer software.<br><br>Verify your installation by creating and accessing a page with a portlet on it.</li><li>If
+the application server you are using isn't a fully compliant JavaEE
+server (i.e. it doesn't contain a Faces implementation) there is no
+need to download/install your own version. You will be able to
+leverage Maven when it builds the TCK test suite wars to package/bundle
+the Faces version/impl of your choice directly into the war (as long as
+the version is available in an external Maven respository
+ -- which is the case for both Mojarra and MyFaces).</li><li>Do a Subversion checkout of the TCK project in a working directory of your choice:<br><span style="font-family: monospace; font-weight: bold;">cd \myTCK</span><br><span style="font-weight: bold; font-family: monospace;">svn checkout </span><font style="font-family: monospace; font-weight: bold;" size="3">http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0</font> </li></ol>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><h2>Chapter 5 </h2><h1><a name="TCK_Project_Structure"></a>TCK Project Structure</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>Once you have successfully checked out the TCK project using subversion. You will see the following structure:<br><br><table style="text-align: left; width: 595px; height: 75px;" border="1" cellpad
ding="2" cellspacing="2"><tbody><tr><td style="vertical-align: top; white-space: nowrap;"><span style="font-family: monospace;">\Bridge301TCK</span><br style="font-family: monospace;"><div style="margin-left: 40px;"><span style="font-family: monospace;">pom.xml</span><br><span style="font-family: monospace;">tck-generate-test-wars.cmd</span><br style="font-family: monospace;"><span style="font-family: monospace;">tck-run-tests.cmd</span><span style="font-family: monospace;"></span><br><span style="font-family: monospace;">\client</span><br style="font-family: monospace;"><span style="font-family: monospace;">\portlet-bridge-tck-main</span><br style="font-family: monospace;"><span style="font-family: monospace;">\portlet-bridge-tck-section3-2-lifecycle-set</span><br style="font-family: monospace;"><span style="font-family: monospace;">\portlet-bridge-tck-section3-2-render-policy-always-delegate</span><br style="font-family: monospace;"><span style="font-family: monospace;">\p
ortlet-bridge-tck-section3-2-render-policy-default</span><br style="font-family: monospace;"><span style="font-family: monospace;">\portlet-bridge-tck-section3-2-render-policy-never-delegate</span><br style="font-family: monospace;"><span style="font-family: monospace;">\src</span></div></td></tr></tbody></table><br><span style="font-weight: bold;">\src</span>
+contains all the shared sources between the various test apps.
+ This includes the tests themselves, plus the non-app specific
+resource files (like the exclusions file which is located in <span style="font-weight: bold;">src\test\resources\test-exclusions.xml</span>).<br><br><span style="font-weight: bold;">\portlet-bridge-tck-main</span> holds the main test application. 99% of the tests are represented within this application.<br><span style="font-weight: bold;">\portlet-bridge-tck-section3-2-lifecycle-set</span>
+holds an additional test application. The main test application
+includes a test to verify that when using the default configuration the
+Bridge uses the default Faces Lifecycle. This application runs
+the same test however the web application (web.xml) is configured so
+that Faces/Bridge will use a specific Lifecycle implementation.<br><br>The three <span style="font-weight: bold;">render-policy</span>
+subdirectories build distinct web applications each of which represent
+the same (render-policy) test but with a distinct configuration.
+ However because the render-policy test is an excluded test, the
+TCK build commands (are commented out and) do not build or run these test
+applications. To manually run these tests, if your environment
+can support them, you will need to uncomment out some lines in the root
+project pom.xml. See the exclusions file in
+src\test\resources\test-exclusions.xml for further information.<br><br><span style="font-weight: bold;">\client</span> contains project definitions for using the TCK to generate test
+definition files and for running the TCK against an external server. When you run the TCK against an
+external (non-Jetty) server, the run/results are output into the
+\client\target subdirectory.<br><h4>pom.xml</h4>The
+pom.xml file contains the primary Maven definitions for building and
+running the TCK. Though each of the subdirectories also contain
+pom.xml's these are child pom's that all rely/reference this one.
+ In general you should not modify any of the pom.xml files.
+ The one exception is if you decide to customize this root pom.xml
+by changing its property definitions that relate to the particular
+instance of the Bridge or Faces that the TCK relies on/uses by default.<br><br><h4>tck-generate-test-wars.cmd</h4>The <span style="font-family: monospace;">tck-generate-test-wars.cmd</span>
+file is a simple (shell) script that executes the default Maven command
+for generating the test war files modfiied by whatever command line
+arguments you include. Once you figure out your common usage,
+modify this script so you don't have to keep reentering the (lengthy)
+set of arguments.<br><br><h4>tck-run-tests.cmd</h4> The <span style="font-family: monospace;">tck-run-tests.cmd</span><span style="font-weight: bold;"> </span>file
+is a simple (shell) script that executes the default Maven command for
+running the test harness to execute the tests installed in your target
+test application server. To accomplish this test harness will
+need the following information from you:<br><ol><li>location of the file containing the description of the tests (URLs) to be run.</li><li>location
+of the file containing authentication/credential information (used if
+the test server's portal challenges the test harness).</li><li>The host and port the test server is listening on.</li></ol>When using this script, these are preset in environment variables:<br><ol><li>TCK_CONFIG_HOME:
+ This variable defines a home directory containing a test.xml and
+login.properties file used to configure the harness. Use this
+variable instead of the TCK_TEST_FILE and TCK_LOGIN_FILE environment
+variables if you use the standard names.</li><li>TCK_TEST_FILE:
+This variable defines the path to the file containing the URLs for each
+of the tests to be run in your test server. See XXXX for
+where/how this file is generated.</li><li>TCK_LOGIN_FILE: This variable defines
+the path to the file containing the username and password to be used by
+the test harness to authenicate itself when its challenged by the
+portal when it runs the tests.</li><li>TCK_CLIENT_HOST: This variable defines the host where the test server is located.</li><li>TCK_CLIENT_PORT: This variable defines the port on the hsot that the test server is listening on.</li></ol>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><br><br><h2>Chapter 6</h2><h1><a name="Testing_a_Vendor_Implementation"></a>Testing a Vendor Implementation</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>This chapter describes a generic Bridge TCK configuration to work with
+a vendor implementation. See <a href="#Testing_a_Vendor_Implementation_in_a">Chapter 7</a>,
+"Testing a Vendor Implementation in a Pluto Environment" if you are
+testing your Bridge implementation using Apache Pluto. See <a href="#Verifying_the_Reference_Implementation">Chapter 8</a>, Verifying the Reference<br>
+Implementation in Your Environment” for information on running Bridge TCK against the
+reference implementation from Apache MyFaces PortletBridge Project.<br><br>Before proceeeding, you may want to review the <a href="#Typical_Usage">typical usage description</a> from chapter 1. <br><br>Note:
+Much of the following relies on Maven commands to build and execute the
+TCK. Maven commands are typically configured by using command
+line arguments. As you will see this can often get unwieldly.
+ It is recommended that you either create templates for your often
+used commands, (shell) script files, modify the property definitions
+in the pom.xml file in the project's root directory directly, or use profiles to define groups of properties.
+<a class="moz-txt-link-freetext" href="http://maven.apache.org/guides/introduction/introduction-to-profiles.html">http://maven.apache.org/guides/introduction/introduction-to-profiles.html</a>. <br><br><h3>Publish your Bridge to the (local) Maven repository</h3>Because
+the TCK is controlled by running Maven, prior to building and running
+the Bridge TCK you need to have published your Bridge implementation to
+a maven repository. If the one you want to test isn't already in
+an (accessible) external repository, then you need to publish it to
+your local repository. It is assumed your bridge implementation
+is contained in two jars, one containing the required implementations
+for the public/specified API interfaces and classes corresponding to
+the JavaDoc included with the specification and one containing your
+vendor specific bridge implementation. Both jars are published
+using the following Maven commands:<br><div style="margin-left: 40px;"><span style="font-weight: bold;"> <span style="font-family: monospace;">mvn deploy:deploy-file -DgroupId=</span></span><span style="font-family: monospace;"><</span><span style="font-style: italic; font-family: monospace;">your bridge groupId</span><span style="font-family: monospace;">> </span><span style="font-weight: bold; font-family: monospace;">-DartifactId=</span><span style="font-family: monospace;"><</span><span style="font-style: italic; font-family: monospace;">your artifactId for the bridge api</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dversion=</span><</span><span style="font-style: italic; font-family: monospace;">your version number</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dpackaging=jar</span> <span style="font-weight: bold;">-Dfile=</span><l</span><span style="font-style: italic; fo
nt-family: monospace;">ocation of bridge API jar</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Durl=</span><</span><span style="font-style: italic; font-family: monospace;">local file path to root of maven repository</span><span style="font-family: monospace;">></span><br><br><span style="font-family: monospace;"><span style="font-weight: bold;">mvn deploy:deploy-file -DgroupId=</span><</span><span style="font-style: italic; font-family: monospace;">your bridge groupId</span><span style="font-family: monospace;">>
+<span style="font-weight: bold;">-DartifactId=</span><</span><span style="font-style: italic; font-family: monospace;">your artifactId for the bridge impl</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dversion=</span><</span><span style="font-style: italic; font-family: monospace;">your
+version number</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dpackaging=jar -Dfile=</span><</span><span style="font-style: italic; font-family: monospace;">location of bridge Impl
+jar</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Durl=</span><</span><span style="font-style: italic; font-family: monospace;">local file path to root of maven repository</span><span style="font-family: monospace;">></span></div><br>For
+example: If I wanted to publish Oracle's bridge to my
+local repository using a maven groupid of oracle.portlet.bridge I
+might use:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn
+deploy:deploy-file -DgroupId=oracle.portlet.bridge
+-DartifactId=bridge-api -Dversion=1.0.0 -Dpackaging=jar
+-Dfile=c:\bridge\oracle\portlet-bridge-api-1.0.0.jar
+-Durl=file://"c:\Documents and Settings\myloginname\.m2"</span><br><br><span style="font-family: monospace;">mvn
+deploy:deploy-file -DgroupId=oracle.portlet.bridge
+-DartifactId=bridge-impl -Dversion=1.0.0 -Dpackaging=jar
+-Dfile=c:\bridge\oracle\portlet-bridge-impl-1.0.0.jar
+-Durl=file://"c:\Documents and Settings\myloginname\.m2"</span></div> <br><br><h3>Generate the TCK TestSuite Portlet Applications (.wars)</h3>The
+TCK TestSuite Portlet Application .wars are built using a Maven
+command. Two test applications are built: <font size="3">portlet-bridge-tck-main-jsr301-1.0.0</font> is generated in
+\portlet-bridge-tck-main\target while
+portlet-bridge-tck-section3-2-lifecycle-set-<font size="3">jsr301-1.0.0</font>.war is
+generated in \portlet-bridge-tck-section3-2-lifecycle-set\target.<br><h4>Maven command used when the Bridge and Faces are already deployed in the Test AppServer</h4>The
+following command will build the two test war files without packaging
+either the Bridge jars or the Faces jars into these wars. (i.e.
+use this command if the Bridge and Faces software is already
+installed/available in your test application server.<br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: italic;">your version number</span>></span></div><br>For example<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font
-family: monospace;"> -Dportlet-bridge.version=1.0.0</span></div><br><h4>Maven command which additionally includes the Bridge in generated wars.</h4>The
+following command will build the two test war files which will include the Bridge jars. <br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war -DincludeBridge -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;"></span></span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.impl.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge <span style="font-family: monospace;">impl></span></span> </span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: italic;">your version number</span>></span><
/div><br>For example<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war -DincludeBridge -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl</span><span style="font-family: monospace;"> -Dportlet-bridge.version=1.0.0</span></div><br><br><h4>Maven command which additionally includes JSF in generated wars.</h4>The
+following command will build the two test war files including both the JSF jars and the Bridge jars. <br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war -DincludeJSF=[mojarra|myfaces] -DincludeBridge -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;"></span></span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.impl.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge <span style="font-family: monospace;">impl></span></span> </span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: ita
lic;">your version number</span>></span></div><br>For example to include the Mojarra JSF jars in your wars:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war -DincludeJSF=mojarra -DincludeBridge -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl </span><span style="font-family: monospace;">-Dportlet-bridge.version=1.0.0</span></div><br>Or to include the MyFaces JSF jars in your wars:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war -DincludeJSF=myfaces -DincludeBridge -Dportlet-bridge.groupId=</span><
span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl </span><span style="font-family: monospace;">-Dportlet-bridge.version=1.0.0</span></div><br>Note:
+ Each of the above commands includes the default version of either
+Mojarra or MyFaces in the resulting wars. The default version is
+controlled by the the Maven poroperty mojarra.version or
+myfaces.version. Currently these are the minimum versions
+demanded by the specification: 1.2_03 and 1.2.2, respectively. To
+override these with a later version include -Dmojarra.version or
+-Dmyfaces.version set to the intended version in the above command line.<br><br><h3>Configure Test Server</h3><br>Once
+the test applications have been built, deploy them to the test server.
+ Once deployed, expose each test via a distinct browser accessible
+URL. I.e. place each portlet on a separate portal page. At
+this point you should be able to verify your deployment/setup by
+running test(s) manually by accessing the specific portal pages. <br><br><h3>Run the TestHarness to Execute the TCK</h3>The
+TestHarness runs the TCK by processing a test description file.
+ The test description file is an XML file called test.xml.
+ It contains one entry for each test the harness is to run.
+ The XML syntax for a test description has the form:<br><div style="margin-left: 40px;"><pre><entry key="<span style="font-style: italic;">testURL</span>"><span style="font-style: italic;">testName</span></entry></pre></div><br>where <span style="font-style: italic;">testURL</span> is the full URL path to the (page containing the) test and <span style="font-style: italic;">testName</span>
+is the short name of the test. A test's short name is derived
+from the test's portlet name. A test's portlet name has the form:
+<span style="font-style: italic;">SpecificationSection</span>-<span style="font-style: italic;">Test(short)Name</span>-portlet. <br><br><h4>Generating the Test Description File</h4>Prior
+to running the TestHarness you will need to configure/generate an
+appropriate version of this test.xml for your specific configuration.
+ Though the project contains a pre-generated template of the
+test.xml file (src\test\resources\test.xml) its best to generate your
+own template file to ensure absolute consistency with the current
+verion of the TCK. The following command will generate a template
+test.xml.<br><br><div style="margin-left: 40px;"><span style="font-weight: bold;">mvn generate-test-resources -Dtck.external-server=generate-test-file-template</span></div><br>The
+command uses a stylesheet included in the TCK src directory to
+transform the portlet.xml for the main Test App into a test.xml
+template (plus its adds the additional test in the other Test app).
+ One test.xml entry is created for each portlet in the
+portlet.xml. The
+resulting test.xml will be located in the /client/target and contain N
+test entries in the form <entry
+key="page-servlet-path">XXXTestname</entry> where XXXTestname
+varies for each test name that is to be run. To transform this
+template into one that works for your server, merely replace the
+"page-servlet-path" value in each entry with the appropriate URL to the
+page containing the specific test named by XXXTestname. For
+example in a Pluto environment you might end up with the following
+entry:<br><div style="margin-left: 40px;"><pre><entry key="pluto/portal/TestPage001">bridgeVersionTest</entry></pre></div><br>Alternatively you can write an xsl script to transform this file and specify it as an alternative on the command line:<br><div style="margin-left: 40px;"><div style="margin-left: 40px;"><span style="font-weight: bold;">mvn generate-test-resources -Dtck.external-server=generate-test-file-template -Dbridge.tck.stylesheet=<span style="font-style: italic;">/pathtostylsheet/yoursytlesheet.xsl</span></span></div></div><br>Note: because using the above command(s) utilizes Maven, any following Maven command that cleans the project (includes <span style="font-weight: bold;">clean</span> in its command line) will delete all the project's <span style="font-weight: bold;">target</span> directories including the one containing this generated <span style="font-weight: bold;">test.xml</span>
+file. As one commonly only needs to generate this file once,
+after it has been generated it is recommended you move this file to a
+location outside the target directory. For example merely move it
+to <span style="font-weight: bold;">TCK_PROJECT_HOME/client.</span><br><h4>Configuring a login file</h4>As
+most portals require user authentication to access pages, in addition
+to configuring a test description file, its (often) necessary to also
+create and configure a <span style="font-weight: bold;">login.properties</span>
+file so the harness can properly authenticate itself when challenged.
+ The TestHarness, as its running Selenium, handles authentication
+as it does all page requests, it looks for specific named
+fields/buttons in the page response to determine what it should do/send
+in the next request. The <span style="font-weight: bold;">login.properties</span> file therefore contains the name/value pairs of the form fields and button for the portal's login page. I.e. the <span style="font-weight: bold;">login.properties</span> file has the form:<br><div style="margin-left: 40px;"><span style="font-style: italic;">field1Id</span>=field1Value<br><span style="font-style: italic;">field2Id</span>-field2Value<br><span style="font-style: italic;">SubmitButtonId</span></div><br>Note: input fields are donoted as name/value pairs while the submit button is represented by only its name (id).<br><br>For example the login.properties file for Pluto is:<br><div style="margin-left: 40px;">j_username=pluto<br>j_password=pluto<br>j_login</div><br>In
+every request sent by the TestHarness the harness looks at the response
+and if the first field from the login.properties file is present it
+sets each of the fields identified in the login.properties file with
+their associated value and submits the form (via the indicated submit
+button).<br><br>If your test server will present a login screen to the TestHarness when it executes page requests from the <span style="font-weight: bold;">test.xml</span> file, create a <span style="font-weight: bold;">login.properties</span>
+file with the appropriate information using the above syntax. It
+is recommended you locate this file in the same location as the <span style="font-weight: bold;">test.xml</span> file.<br><h4>Running the TestHarness </h4>After properly configuring and deploying the TCK tests to your test server and creating an appropriate <span style="font-weight: bold;">test.xml </span>and <span style="font-weight: bold;">login.properites</span>
+(if necessary) file, run the TestHarness to execute the tests and
+generate the test reports by using the following command:<br><br><div style="margin-left: 40px;"><span style="font-weight: bold;">mvn </span><tt><span style="font-weight: bold;">surefire-report:report -Dtck.external-server=run-test
+-Dbridge.tck.test.file=</span><<span style="font-style: italic;">path to test.xml</span>>
+<span style="font-weight: bold;">-Dbridge.tck.test.host=</span><<span style="font-style: italic;">host name</span>>
+<span style="font-weight: bold;">-Dbridge.tck.test.port=</span><<span style="font-style: italic;">port</span>> <span style="font-weight: bold;">[-Dbridge.tck.login-file=</span><<span style="font-style: italic;">path
+to login file</span>><span style="font-weight: bold;">]</span></tt></div><br><br>For example to run the tests and generate the test report in a situation where the test server is on the <span style="font-weight: bold;">bridge-testserver</span> port <span style="font-weight: bold;">80</span> and the test.xml and login.properties file both live in the <span style="font-weight: bold;">TCK_HOME/client</span> directory:<br><br><div style="margin-left: 40px;"><span style="font-weight: bold;">mvn </span><tt><span style="font-weight: bold;">surefire-report:report -Dtck.external-server=run-test
+-Dbridge.tck.test.file=</span></tt><span style="font-family: monospace; font-weight: bold;">c:\bridgeTCK\client\test.xml</span><tt>
+
+<span style="font-weight: bold;">-Dbridge.tck.test.host=bridge-testserver -Dbridge.tck.test.port<span style="font-weight: bold;">=</span></span><span style="font-family: mon; font-weight: bold;">80</span><span style="font-style: italic;"></span> <span style="font-weight: bold;">-Dbridge.tck.login-file=</span></tt><span style="font-family: monospace; font-weight: bold;">c:\bridgeTCK\client\login.properties</span><tt><span style="font-weight: bold;"></span></tt></div> <br><br>Note: the default value for bridge.tck.test.host is <span style="font-weight: bold;">localhost </span>and the default value for bridge.tck.test.port is <span style="font-weight: bold;">8080</span>. You only need to define these properties on the command line if you are not using the default(s).<br><br>The above command builds the TestHarness client and then executes it by launching
+JUnit and Selenium. Two browser windows will be activated. The first
+runs Selenium Remote Control and the second the execution of each test.
+ When the harness completes JUnit is used to generate the test reports.
+ The reports are output
+to TCK_HOME/client/target/portlet-bridge-tck-client-report.html.
+ The raw data from which this report is generated is contained in
+TCK_HOME/client/target/surefire-reports<br><br>Note: One test,
+destroyActionTest, can only be run successfully once per portlet
+activation (i.e. the application containing this test and/or the server
+must be bounced before this test can run successfully again).<br><br><h4>Alternative to lengthy Maven command lines</h4>As
+Maven doesn't provide a way to pull its properties directly from the
+environment, command lines including the variety of property
+definitions needed to operate the TCK can become quite lengthy.
+ Once you determine those commands that satisfy your needs, you
+might consider writing (shell) scripts to make execution easier.
+ The TCK_HOME directory contains two .cmd files
+(tck-generate-test-wars.cmd and tck-run-tests.cmd) which you can either
+use directly are alter to better suit your needs.<br><br>[<a href="Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html#Table_of_Contents">return to TOC</a>]<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><h2>Chapter 7</h2><h1><a name="Testing_a_Vendor_Implementation_in_a"></a>Testing a Vendor Implementation in a Pluto Environment</h1><hr style="width: 100%; height: 2px;"><br><br><br><br>As
+Apache Pluto is the reference implementation for the Java Portlet
+container, and the Bridge reference implementation is also an Apache
+project, efforts have been made in the TCK to simplify testing your
+vendor implementation running on Pluto.<br><br><h3>Publish your Bridge to the (local) Maven repository</h3>Because
+the TCK is controlled by running Maven, prior to building and running
+the Bridge TCK you need to have published your Bridge implementation to
+a maven repository. If the one you want to test isn't already in
+an (accessible) external repository, then you need to publish it to
+your local repository. It is assumed your bridge implementation
+is contained in two jars, one containing the required implementations
+for the public/specified API interfaces and classes corresponding to
+the JavaDoc included with the specification and one containing your
+vendor specific bridge implementation. Both jars are published
+using the following Maven commands:<br><div style="margin-left: 40px;"><span style="font-weight: bold;"> <span style="font-family: monospace;">mvn deploy:deploy-file -DgroupId=</span></span><span style="font-family: monospace;"><</span><span style="font-style: italic; font-family: monospace;">your bridge groupId</span><span style="font-family: monospace;">> </span><span style="font-weight: bold; font-family: monospace;">-DartifactId=</span><span style="font-family: monospace;"><</span><span style="font-style: italic; font-family: monospace;">your artifactId for the bridge api</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dversion=</span><</span><span style="font-style: italic; font-family: monospace;">your version number</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dpackaging=jar</span> <span style="font-weight: bold;">-Dfile=</span><l</span><span style="font-style: italic; fo
nt-family: monospace;">ocation of bridge API jar</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Durl=</span><</span><span style="font-style: italic; font-family: monospace;">local file path to root of maven repository</span><span style="font-family: monospace;">></span><br><br><span style="font-family: monospace;"><span style="font-weight: bold;">mvn deploy:deploy-file -DgroupId=</span><</span><span style="font-style: italic; font-family: monospace;">your bridge groupId</span><span style="font-family: monospace;">>
+<span style="font-weight: bold;">-DartifactId=</span><</span><span style="font-style: italic; font-family: monospace;">your artifactId for the bridge impl</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dversion=</span><</span><span style="font-style: italic; font-family: monospace;">your
+version number</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Dpackaging=jar -Dfile=</span><</span><span style="font-style: italic; font-family: monospace;">location of bridge Impl
+jar</span><span style="font-family: monospace;">> <span style="font-weight: bold;">-Durl=</span><</span><span style="font-style: italic; font-family: monospace;">local file path to root of maven repository</span><span style="font-family: monospace;">></span></div><br>For
+example: If I wanted to publish Oracle's bridge to my
+local repository using a maven groupid of oracle.portlet.bridge I
+might use:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn
+deploy:deploy-file -DgroupId=oracle.portlet.bridge
+-DartifactId=bridge-api -Dversion=1.0.0 -Dpackaging=jar
+-Dfile=c:\bridge\oracle\portlet-bridge-api-1.0.0.jar
+-Durl=file://"c:\Documents and Settings\myloginname\.m2"</span><br><br><span style="font-family: monospace;">mvn
+deploy:deploy-file -DgroupId=oracle.portlet.bridge
+-DartifactId=bridge-impl -Dversion=1.0.0 -Dpackaging=jar
+-Dfile=c:\bridge\oracle\portlet-bridge-impl-1.0.0.jar
+-Durl=file://"c:\Documents and Settings\myloginname\.m2"</span></div> <br><br><h3><a name="Generate_the_TCK_TestSuite_Portlet"></a>Generate the TCK TestSuite Portlet Applications (.wars)</h3>The
+TCK TestSuite Portlet Application .wars are built using a Maven
+command. Two test applications are built: <font size="3">portlet-bridge-tck-main-jsr301-1.0.0</font> is generated in
+\portlet-bridge-tck-main\target while
+portlet-bridge-tck-section3-2-lifecycle-set-<font size="3">jsr301-1.0.0</font>.war is
+generated in \portlet-bridge-tck-section3-2-lifecycle-set\target.<br><br>Portlet
+Applications built to be deployed on Pluto require additional
+configuration in the application's web.xml to relate the portlets to
+the Pluto servlet. This configuration information differs for a
+Pluto 1.0 container and a Pluto 2.0. Using any of the following
+commands will generate Pluto deployable .wars (with web.xml's already
+properly configured).<br><h4>Maven command used when the Bridge and Faces are already deployed in the Test AppServer</h4>The
+following command will build the two test war files without packaging
+either the Bridge jars or the Faces jars into these wars. (i.e.
+use this command if the Bridge and Faces software is already
+installed/available in your test application server.<br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war=[pluto1.0|pluto2.0] -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: italic;">your version number</span>></span></div><br>For example to build the TCK wars for a Pluto 2.0 environment:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war=pluto2.0 -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId
=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> -Dportlet-bridge.version=1.0.0</span></div><br><h4>Maven command which additionally includes the Bridge in generated wars.</h4>The
+following command will build the two test war files including the Bridge jars. <br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war</span></span><span style="font-family: monospace;"><span style="font-weight: bold;">=[pluto1.0|pluto2.0]</span></span><span style="font-family: monospace;"><span style="font-weight: bold;"> -DincludeBridge -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;"></span></span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.impl.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge <span style="font-family: monospace;">impl></span></span> </spa
n><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: italic;">your version number</span>></span></div><br>For example<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war</span><span style="font-family: monospace;">=pluto2.0</span><span style="font-family: monospace;"> -DincludeBridge -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl </span><span style="font-family: monospace;">-Dportlet-bridge.version=1.0.0</span></div><br><br><h4>Maven command which additionally includes JSF in gen
erated wars.</h4>The
+following command will build the two test war files including both the JSF jars and the Bridge jars. <br><br><div style="margin-left: 40px;"><span style="font-family: monospace;"><span style="font-weight: bold;">mvn clean install -Dtck.generate-war</span></span><span style="font-family: monospace;"><span style="font-weight: bold;">=[pluto1.0|pluto2.0]</span></span><span style="font-family: monospace;"><span style="font-weight: bold;"> -DincludeJSF=[mojarra|myfaces] -DincludeBridge -Dportlet-bridge.groupId=</span><<span style="font-style: italic;">your bridge groupId</span>> <span style="font-weight: bold;">-Dportlet-bridge.api.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge api</span>> <span style="font-weight: bold;"></span></span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.impl.artifactId=</span><<span style="font-style: italic;">your artifactId for the bridge <span style="
font-family: monospace;">impl></span></span> </span><span style="font-family: monospace;"><span style="font-weight: bold;">-Dportlet-bridge.version=</span><<span style="font-style: italic;">your version number</span>></span></div><br>For example to include the Mojarra JSF jars in your wars:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war</span><span style="font-family: monospace;">=pluto2.0</span><span style="font-family: monospace;"> -DincludeJSF=mojarra -DincludeBridge -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl </span><span style="font-family:
monospace;">-Dportlet-bridge.version=1.0.0</span></div><br>Or to include the MyFaces JSF jars in your wars:<br><div style="margin-left: 40px;"><span style="font-family: monospace;">mvn clean install -Dtck.generate-war</span><span style="font-family: monospace;">=pluto2.0</span><span style="font-family: monospace;"> -DincludeJSF=myfaces -DincludeBridge -Dportlet-bridge.groupId=</span><span style="font-family: monospace;">oracle.portlet.bridge</span><span style="font-family: monospace;"> -Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-api</span><span style="font-family: monospace;"> </span><span style="font-family: monospace;">-Dportlet-bridge.api.artifactId=</span><span style="font-family: monospace;">bridge-impl </span><span style="font-family: monospace;">-Dportlet-bridge.version=1.0.0</span></div><br>Note:
+ Each of the above commands includes the default version of either
+Mojarra or MyFaces in the resulting wars. The default version is
+controlled by the the Maven poroperty mojarra.version or
+myfaces.version. Currently these are the minimum versions
+demanded by the specification: 1.2_03 and 1.2.2, respectively. To
+override these with a later version include -Dmojarra.version or
+-Dmyfaces.version set to the intended version in the above command line.<br><br><h3>Configure Test Server</h3><br>Once
+the test applications have been built, deploy them to the test server.
+ Once deployed, expose each test via a distinct browser accessible
+URL. I.e. place each portlet on a separate portal page. At
+this point you should be able to verify your deployment/setup by
+running test(s) manually by accessing the specific portal pages. <br><br>To
+avoid the labor intensive step of manually creating the test pages copy
+TCK_HOME/src/test/resources/tomcat_pluto/pluto-portal-driver-config.xml
+to your applications server's deployed Pluto application's WEB-INF
+directory replacing the one that exists there. This file
+maintains Pluto's repository of its portal pages. It has been
+preconfigured to represent/hold all of the tests.<br><br><h3>Run the TestHarness to Execute the TCK</h3>The
+TestHarness runs the TCK by processing a test description file.
+ The test description file is an XML file called test.xml.
[... 310 lines stripped ...]