To control which stubs are published, use the stubFilter option. By default, all stubs within the project are published. Stub filters work by specifying the names of the components, operation and folders where the stub resides. To specifying this information on the command line, you specify XML-like tags with an appropriate name. For example, to publish all stubs under a component that is called 'Test Component', the following stub filter would be sufficient:
--stubFilter “<C>Test Component</C>”
Here, the tag '<C>' denotes filtering by a component name. In this context, a component refers to any top level node that acts as a container for stubs. Examples would be a service component, database server, WebSphere® Application Server component, WSDL component. You can specify the following tags:
<C> or <c> - for Component path
<O> or <o> - for Operation name
<F> or <f> - for Folder path
All tags are optional and can be defined in any order. If a tag value is not supplied, it defaults to accepting any value for that component, operation, or folder filter. The following filter publishes all stubs that belong to an operation called Send Message no matter what component and folder structure they belong to.
--stubFilter “<O>Send Message</O>”
If multiple instances of the same tag are included in the filter, only the last tag is used. To publish to multiple components, operations or folders, you define multiple filters on the command by separating each one with a semi-colon (;). For example, the following filter publishes all stubs under the component Component 1 that belong to the Buy operation and also publishes all stubs under the Big Database component that are included under the myFolder folder.
--stubFilter “<C>Component 1</C><O>Buy</O>;<C>Big Database</C><F>/myFolder</F>”
There is no limit to the number of filters that you can specify this way.
Because components and folders can be nested, the component and folder tags specify a component or folder hierarchy by separating each one by a forward slash (/). A preceding and terminating slash is not required though supported. For example, to publish only StubC in the following project hierarchy, the following filter would be sufficient:
--stubFilter “<C>CompA/CompC</C><O>OpB</O><F>FolderA/FolderB</F>”
Instead of specifying the value of a tag, you can use the wildcard character, an asterisk (*). This filter will then accept any value for a node represented by that tag. For example, to publish all stubs under the Send Message operation in any component, the following filter would be sufficient:
--stubFilter “<C>*</C><O>Send Message</O>”
A wildcard is the default value when not specified as part of the filter. If a stub filter contains invalid content such as incorrectly closed tags or data that does not match one of the supported tags, stub publishing fails and the user is informed that their filter definition contains invalid data.
Note: This syntax contains special characters so, in the context of Ant tasks, they would either need to be escaped, or be loaded from a file using the property task:
<property file="stub_publish.properties"/>
--majorVersion 3 –-minorVersion 1
--minorVersion ++
Version | Published Stubs |
---|---|
1 | StubA, StubB, and StubC |
2 | StubA, and StubB |
The options file can be used to pass both simple and complex options to the command interfaces. This method is available for any interface which supports the optionsFile option.
|
Specifying publishing versions
Rather than specifying a concrete version value to use for the publish, you can set the 'increment' attribute to true or false for the majorVersion and minorVersion elements. This setting will cause the command to get the latest version value of the project on the server for the given domain and environment. If increment is set to true, the latest version value on the server will be incremented by one and used as the version value for the current publish.Specifying a stub filter
You specify a stub filter to select which stubs will be published by the command. If a filter is not specified, all stubs found in the project are published by default.In the options file, you specify a stub filter by adding component, operation and folder XML elements as child elements of the stubFilter element. You must specify the name of the component, operation, or folder that stubs should be filtered by, by adding a 'name' attribute to the element. The hierarchy of these elements should match the path to the stub(s) to be published in the Test Factory perspective within IBM Rational Integration Tester. For example, the following stubFilter entry in the options file can be used to only publish StubC.
<stubFilter>
<component name="CompA">
<component name="CompC">
<operation name="OpB">
<folder name="FolderA">
<folder name="FolderB"/>
</folder>
</operation>
</component>
</component>
</stubFilter>