Team Process - 확장 패러미터 정의

프로젝트 영역의 프로세스 구성소스 예

    <followup-action xmlns="http://com.example.modify/addNewTodo"
                            id="com.example.modify.addNewTodo" name="Add New Todo (Modify)">
        <workitem-type-id value="example.type.todo"/>
        <workitem-list-attrib-id value="example.attribute.defect_list"/>
    </followup-action>

플러그인 소스의 예

public class AddNewTodo extends AbstractService implements IOperationParticipant
{
    public void run(AdvisableOperation operation,
            IProcessConfigurationElement participantConfig,
            IParticipantInfoCollector collector, IProgressMonitor monitor)
            throws TeamRepositoryException {

        IProcessConfigurationElement[] processConfig = participantConfig.getChildren();
        for (IProcessConfigurationElement element : processConfig) {
            if (element.getName().equals("workitem-type-id")) {
                String fWorkItemTypeId = element.getAttribute("value");
            } else if (element.getName().equals("workitem-list-attrib-id")) {
                String fWorkItemListAttribId = element.getAttribute("value");
            }
        }
   
    }
}

플러그인에서의 스키마 정의 예

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns="http://com.example.modify/addNewTodo"
   targetNamespace="http://com.example.modify/addNewTodo"
   xmlns:process="http://com.ibm.team.process"
   attributeFormDefault="unqualified" elementFormDefault="qualified">

   <xsd:import namespace="http://com.ibm.team.process"
      schemaLocation="platform:/plugin/com.ibm.team.process.common/schema/ProcessSettings.xsd"/>

   <xsd:complexType name="addNewTodoType">
      <xsd:complexContent>
         <xsd:restriction base="process:followupActionType">
            <xsd:all>
                <xsd:element name="workitem-type-id" minOccurs="1" maxOccurs="1">
                    <xsd:complexType>
                        <xsd:attribute name="value" type="xsd:string" use="required"/>
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="workitem-list-attrib-id" minOccurs="1" maxOccurs="1">
                    <xsd:complexType>
                        <xsd:attribute name="value" type="xsd:string" use="required"/>
                    </xsd:complexType>
                </xsd:element>
            </xsd:all>
            <xsd:attribute name="id" type="xsd:string" use="required" fixed="com.example.modify.addNewTodo"/>
         </xsd:restriction>
      </xsd:complexContent>
   </xsd:complexType>
   <xsd:element name="followup-action" substitutionGroup="process:followup-action" type="addNewTodoType"/>
</xsd:schema>

https://jazz.net/wiki/bin/view/Main/ProcessExtensionSchemas

Overview

Process allows components authors to process-enable their component by declaring process operations, configuration data, and events. In addition, component and process authors may extend the library of available operation advisors, participants, and event handlers which are executed by process enabled operations and events. These extensions are declared through the Eclipse extension mechanism. In particular, by declaring extensions to:

• com.ibm.team.process.client.configurationPoints
• com.ibm.team.process.service.configurationPoints
• com.ibm.team.process.client.operationAdvisors
• com.ibm.team.process.service.operationsAdvisors
• com.ibm.team.process.client.operationParticipants
• com.ibm.team.process.service.operationsParticipants
• com.ibm.team.process.service.eventHandlers

All of these process extension points provide for an optional Schema location attribute. If the value is set to a plugin-relative path to an XSD schema file, the process tooling will leverage this schema in the following ways:

• Validation - Process specifications and customizations which reference the elements declared in the schema, will be validated against it and any rule violations will be presented in the process area editor's source tab.
• Content Assistance - In the project area and team area editor source tabs, the schemas will be used to present content assist proposals for the elements declared in the schema.

Process extension schemas may be provided for both client-side and server-side extensions.

Anatomy of a Process Extension Schema

To understand how to create a schema which can be leveraged by the process tooling, let's look at an example. The following is the schema for the prohibit nonexternalized stringsprecondition which is applicable to deliver operations: 

Let's break this down into 4 sections and look at them individually to highlight some of the important aspects.

The schema tag and associated attributes

When declaring your schema, you will need to specify your own target namespace via the targetNamespace attribute. This will help avoid collisions with custom extensions from other component and process authors. In addition, it is often helpful to then declare the default namespace to be the same as your target namespace so that you don't have to prefix the elements you declare in your schema file. Lastly, you will want to consider declaring a prefix for the default process namespace http://com.ibm.team.process since you will need to refer to at least one element from it later.

In this example, the targetNamespace and default namespace (xmlns=...) have been set to http://com.ibm.team.process/prohibitNonexternalizedStrings and the prefix "process" has been declared for the default process namespace.

Default process namespace import

The next section of interest in our example is the import element. This tells the parser where to find the schema for the default process namespace which you will reference in declaring any derived types. You should be able to simply copy and paste this from an existing schema file or the snippets section at the bottom of this document.

Derived type definition

The next section in our example is where the "real" work is done. To allow your custom schema element to appear in a process specification or customization, in place of one of the predefined operation, configuration-data, event, advisor, or participant elements, you will need to define a derived type. In particular, your type should derive either directly or indirectly from the corresponding type in the ProcessSettings.xsd schema (which can be found in the location specified by the schemaLocation attribute on the namespace import described above).

In this example, since the schema is for a precondition, the base type is process:preconditionType. In your own custom schema you would additionally include any other elements, types, enumerations, etc... that are required to properly describe the structure of your extension.

Substitution group

The last interesting part of the example schema is the element definition with the substitutionGroup attribute. What this is doing is defining a new element in your namespace with the same name as the element from the process namespace that you want to be able to be substituted for in process specifications and customizations and then declaring that it should be substitutable for that element.

In the case of this example, we have defined a new precondition whose type is that of our derived type and that is substitutable for the precondition element defined in the process schema (that is, it can appear anywhere a precondition is allowed to appear in a process specification or customization).

Snippets and Examples

The following are snippets and examples that you may find useful in creating your own custom schemas.

Precondition Template

Followup Action Template

Operation Behavior Template

Configuration-Data Template

Enumeration Example

Recursive Element Example (with usage)

--