Requirement tag

Like the capability tag, the requirement tag creates a requirement in the target topology or accesses an existing requirement in the target topology. In either case, you must specify the unit that contains the requirement, either with the owner attribute or by nesting the requirement tag within a unit tag.

Attributes

Table 1. Attributes of the requirement tag
Attribute	Type	Required or optional	Description
displayName	String	Optional	The caption for the requirement.
name	String	Required	The internal name of the requirement. This name is not visible in the topology editor
owner	XPath	Optional	The XPath location of the unit that contains the requirement. If this attribute is not specified, the requirement tag must be within a unit tag that represents the containing unit.
preferNameMatch	Boolean	Optional	If this attribute is set to `true` (the default), the tag matches the requirement with the specified name. If this attribute is set to `false`, the tag matches the requirement with the specified type.
type	String	Required	The type of the unit or capability that can satisfy this requirement. You can specify a capability type such as core.Capability, or a unit type such as core.Unit. To specify that any unit or capability can satisfy the requirement, use `<none>` (with the angle brackets) as the value for this attribute. If you specify a unit type, the topology editor assumes that the requirement requires a membership link. For a list of unit and capability types in the topology editor domains, see Domains supported by the topology editor.
usage	String	Optional	Whether the requirement is required or not. Valid values are: required (the default) optional prohibited
var	String	Optional	The name of a variable to create that refers to the requirement. If you assign a variable name here, you can use that variable in other places in the JET code to refer to the requirement.

Examples

Like the capability tag, you can nest the requirement tag within a unit tag to create a requirement on a unit, as in the following example.

<deploy:unit name="New unit" type="core.Unit">
  <deploy:requirement name="New requirement" 
  type="core.Capability" 
  usage="required"/>
</deploy:unit>

You can also use the owner attribute to specify a containing unit, as shown in the following example.

<%-- create a unit and assign a variable name to it --%>
<deploy:unit name="New unit" type="core.Unit" 
  var="newUnit"/>

<%-- create a requirement on the unit --%>
<deploy:requirement type="core.Capability" 
  name="New capability" 
  usage="required" 
  owner="$newUnit"/>

Like the capability tag, if a requirement exists on the unit with a name and type that matches the name and type attributes on the requirement tag, the requirement tag accesses the existing requirement rather than creating a requirement. If there is no requirement that matches both the name and type attributes, the requirement tag creates a requirement.

To change the type of a requirement, set preferNameMatch to true and specify the name of the requirement in the name attribute. Then, specify the new type in the type attribute.

Unlike the capability tag, the requirement tag has no linkType attribute. To specify the type of link that can satisfy the requirement, use the set tag, as in the following example:

<deploy:unit name="New unit" type="core.Unit">
  <deploy:requirement name="New requirement" type="core.Capability">
    <%-- set link type --%>
    <c:setVariable select="'member'" var="linkTypeVar"/>
    <deploy:set name="linkType" value="$linkTypeVar"/>
  </deploy:requirement>
</deploy:unit>

In this case, the valid values for the linkType attribute are:

hosting (the default)
dependency
member

Feedback