Project: stp

An API through which programs may access IBM Rational requirements, change and configuration management services.

See:
          Description

Packages
com.ibm.rational.wvcm.stp Extensions to the generic interfaces and infrastructure of the Workspace Versioning and Configuration Management (WVCM) API used in all domains.
com.ibm.rational.wvcm.stp.cc ClearCase-specific extensions to IBM Rational CM API and WVCM.
com.ibm.rational.wvcm.stp.cq Extensions to the Workspace Versioning and Configuration Management (WVCM) API providing access to ClearQuest repositories.
javax.wvcm

The specification for the JSR-147 Workspace Versioning and Configuration Management (WVCM) API.

 

An API through which programs may access IBM Rational requirements, change and configuration management services.

The CM API

This CM API is a unified collection of Java interfaces and classes specifying a public API through which programming clients can interact with IBM Rational team products providing requirements, change and configuration management services. Such clients would typically be graphical or command-line user iterfaces or custom scripts or programs needing such services.

To access services through this API, the client invokes javax.wvcm.ProviderFactory.createProvider to instantiate one of the provider classes named in the StpProvider, CqProvider, or CcProvider interfaces.

In this release one StpProvider class is available, PROVIDER_CLASS, which provides access to ClearQuest databases and ClearCase Remote Client servers through the properly installed and licensed IBM Rational products for these resource repositories. Note that this provider does not implement the CqProvider or CqProvider interfaces, but it does contain links to component objects that do. Future releases will provide provider classes for obtaining similar services via other means.

The performance characteristics of this API may vary from operation to operation, although, currently, there is no way for the client to ask the provider which operations are expensive and which are not.

Packaging

The API is partitioned into a number of packages. In addition to the packages for standard and shared interfaces, there is one package for each domain type, which includes proxy interfaces for each resource type supported by the domain and a Provider interface extension that defines factory methods for each of these proxy classes. Clients of this API will use these packages:

For an overview of the API, continue with "core package overview".

Change Log

Since 7.0.0 Tech Preview Release

Location specification syntax
The syntax for specifying locations has been reworked to be upwardly compatible with the format currently used by ClearCase for object selectors and pnames. See StpLocation.
Selector and Location merged
com.ibm.rational.wvcm.Selector and com.ibm.rational.wvcm.Location have been merged into an interface named StpLocation. The various forms of constructors for Selector have been moved to StpProvider as factory methods for the new StpLocation objects. StpLocations can be used both as javax.wvcm.Location objects and to examine and manipulate the various schemes used to specify a location.
USER_FRIENDLY_ and STABLE_LOCATION properties
The properties StpResource.OBJECT_ID_SELECTOR and StpResource.OBJECT_NAME_SELECTOR have been renamed to StpResource.STABLE_LOCATION and StpResource.USER_FRIENDLY_LOCATION, respectively, and now return StpLocation objects rather than Selectors. The use of "SELECTOR" in their name was removed because the locations returned do not need to use the object selector schemes.
PropertyName.nest()
To facilitate the building and readability of static PropertyNameList objects two overloaded nest(...) methods have been added to PropertyNameList.PropertyName, which generate a NestedPropertyName.
Unique class names
To guarantee unique simple names for all classes and interfaces in the API, all interface and class names of the CM API extensions to javax.wvcm now begin with the two- or three-letter simple name of the package in which they are located. Thus ...cq.Record is now named ...cq.CqRecord, and ...stp.Query is now named ...stp.CqQuery. This should make code more readable when using import directives to shorten class names.
Archiving/Restoring Proxies
To facilitate the archiving and restoring of proxies, new methods have been added to the StpResource and StpProvider interfaces.
Provider interfaces split by domain
The former javax.wvcm.Provider and ...stp.StpProvider have been split into two domain-specific interfaces each so that a client working in only one domain is not contaminated with features of other, irrelevant domains. WorkspaceProvider contains the methods specific to configuration management and CqProvider ...cq.CqProvider contains the methods specific to the domains using change contexts. javax.wvcm.Provider and stp.StpProvider are now the respective domain-independent base Provider interfaces.
Provider implementation split by domain
To increase the flexibility in advancing the implementation of each domain provider independently, the Provider has been split into separate, but linked, domain-specific implementation objects. The client can no longer cast a provider object from one domain-specific iterface to another; instead special member functions must be used to get from one domain provider to another.
FORBIDDEN and CONFLICT reason codes clarified
The documentation for the FORBIDDEN and CONFLICT reason codes has been changed to use the wording of the HTTP specification.
Numerous Resource properties removed
The following properties previously defined in the StpResource interface have been dropped from the API
Resource.CREATOR_USERNAME renamed
StpResource.CREATOR_USERNAME has been renamed to StpResource.CREATOR_LOGIN_NAME
doReadMemberList rules revised
For the proxies returned by doReadMemberList, the following exceptions to the WVCM guidelines apply
BOUND_MEMBER_LIST changed to CHILD_BINDING_LIST
Folder.BOUND_MEMBER_LIST has been replaced with Folder.CHILD_BINDING_LIST, whose value is a List of Folder.ChildBinding structures similar in form and function to the Resource.ParentBinding structures returned by PARENT_BINDING_LIST.
Unique resource locations
In this release, each object model resource is addressable in only one user-friendly namespace. In all other user-friendly namespaces where the name of the object model resource is used, the resource addressed is simply a folder. In the initial release, a location involving the name of a resource could be used to access the resource regardless of the namespace that was used.

ClearQuest record types, for example, are located in the "record" namespace, but record type names also appear in the "field" and "action" namespaces to disambiguate the simple names used for actions and fields in different record types. Thus "cq.record:Defect@7.0.0/SAMPL" is the location of the record type named "Defect". In addition, "cq.action:Defect/Submit@7.0.0/SAMPL" is the location of the action named "Submit" for record type "Defect" and "cq.field:Defect/Headline@7.0.0/SAMPL" is the location of the field definition for the "Headline" field of record type "Defect".

In the initial release, both "cq.action:Defect@7.0.0/SAMPL" and "cq.field:Defect/@7.0.0/SAMPL" could also be used to access the record type resource named "Defect". In this release, these locations to not address a record type resource, but address a folder resource, which contains either the actions or fields of the named record type, depending on the namespace used in the location. These folders will have their own unique RESOURCE_IDENTIFIERS.

ClearQuest hook support added
Support for ClearQuest alias record scripts and named hooks has been added.
ClearQuest form support added
ClearQuest form data is now available (as Xml) from a record type resource.


Generated Thu 15-Aug-2013 02:30 AM

Copyright © IBM 2013. All rights reserved.