You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by so...@apache.org on 2010/05/27 00:43:29 UTC
svn commit: r948627 [2/3] - in /myfaces/portlet-bridge/tck/trunk: Portlet
1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html TCK Tests.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=948627&r1=948626&r2=948627&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 May 26 22:43:28 2010
@@ -1,1341 +1,3036 @@
-<!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 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"></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;">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><span style="font-family: monospace;"></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><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 <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-weight: bold;"></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-style: italic;"></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><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 cli
ent 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"></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
[... 3363 lines stripped ...]