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/06/02 19:19:16 UTC
svn commit: r950666 [2/2] - /myfaces/portlet-bridge/tck/trunk/Portlet 1.0
Bridge for JavaServer Faces 1.2 TCK User's Guide.html
Modified: myfaces/portlet-bridge/tck/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html
URL: http://svn.apache.org/viewvc/myfaces/portlet-bridge/tck/trunk/Portlet%201.0%20Bridge%20for%20JavaServer%20Faces%201.2%20TCK%20User%27s%20Guide.html?rev=950666&r1=950665&r2=950666&view=diff
==============================================================================
--- myfaces/portlet-bridge/tck/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html (original)
+++ myfaces/portlet-bridge/tck/trunk/Portlet 1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html Wed Jun 2 17:19:16 2010
@@ -1,3036 +1,2647 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta name="generator" content=
-"HTML Tidy for Linux (vers 7 December 2008), see www.w3.org" />
-<meta content="text/html; charset=us-ascii" 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" id="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" id=
-"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" id="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_" id="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" id="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" id=
-"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 Bridge 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" id="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" id="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 />
-<a href=
-"http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0">
-<font size=
-"3">http://svn.apache.org/repos/asf/myfaces/portlet-bridge/tck/tags/jsr301-tck-1.0.0</font></a> </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></li>
-</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" id=
-"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" cellpadding="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;">Portlet 1.0 Bridge for
-JavaServer Faces 1.2 TCK User's Guide.html</span><br style=
-"font-family: monospace;" />
-<span style="font-family: monospace;">TCK Tests.html</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><br />
-<span style=
-"font-family: monospace;">\portlet-bridge-tck-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;">\portlet-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;">\</span><span style=
-"font-weight: bold;">portlet-bridge-tck-</span><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 <span style=
-"font-weight: bold;">\</span>portlet-bridge-tck-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><span style=
-"font-family: monospace; font-weight: bold;">Portlet 1.0 Bridge for
-JavaServer Faces 1.2 TCK User's Guide.html</span></h4>
-This User Manual.<br />
-<br />
-<h4><span style="font-family: monospace; font-weight: bold;">TCK
-Tests.html</span></h4>
-Provides a short description of each test in the TCK.<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> 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" id=
-"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; font-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><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><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
--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;">-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;">-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
-<span style=
-"font-weight: bold;">/</span>portlet-bridge-tck-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/</span><span style=
-"font-weight: bold;">portlet-bridge-tck-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/</span><span style=
-"font-weight: bold;">portlet-bridge-tck-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\</span><span style="font-family: monospace; font-weight: bold;">portlet-bridge-tck-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-weight: bold;">-Dbridge.tck.login-file=</span></tt><span style="font-family: monospace; font-weight: bold;">c:\bridgeTCK\</span><span style="font-family: monospace; font-weight: bold;">portlet-bridge-tck-client</span><span style="font-family: monospace; font-weight: bold;">\login.properties</span></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/portlet-bridge-tck-client/target/portlet-bridge-tck-client-report.html.
- The raw data from which this report is generated is contained
-in TCK_HOME/portlet-bridge-tck-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" id=
-"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; font-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" id=
-"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><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</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;">-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</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><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=
[... 3676 lines stripped ...]