Evaluatable Type tags
There are three categories of simple evaluatable types: (a) string evaluation, (b) file evaluation, and (c) object evaluation. In addition, there are compound types, or Statements, based on the standard boolean operations (and, or, not, xor).
String Evaluation
These are specific to java.lang.String; see also the object-evaluatables equals, less-than, less-than-or-equal, greater-than, greater-than-or-equal below.
<ends-with>
...
<ends-with string="${s1}" suffix="${s3}"/>
...
<equals-ignore-case>
...
<equals-ignore-case first="${s1}" second="${s0}"/>
...
<is-substring-of>
With or without a from (character number) attribute.
...
<is-substring-of string="${s1}" substring="${s3}"/>
<is-substring-of string="${s1}" substring="${s3}" from="12"/>
...
<matches>
This object-evaluatable tag has special attributes for string matching:
...
<matches string="${s1}" regexPattern=".*EF.*"/>
...
File Evaluation
<checksum>
Uses the java.util.zip.Checksum interface and its provided implementation java.util.zip.CRC32 to compare the contents of two files.
...
<checksum first="${f1}" second="${f2}"/>
...
<contains>
This can be used to check the character contents of a file for a matching pattern. One can search the entire file, or indicate the number of lines from the beginning or end to check; one can also simply check the number of lines in the file.
...
<contains path="${f1}" pattern=".*arossi.*" maxPatternLength="512000"/>
<contains path="${f1}" pattern=".*arossi.*" linesFromStart="3"/>
<contains path="${f1}" pattern=".*arossi.*" linesFromEnd="1"/>
<contains path="${f1}" numberOfLines="10" comparator="GE"/>
...
The implementation uses a streamed matching procedure for scalability; this involves a special regular expression filter with an internal buffer, which is scanned and shifted at each match according to a value representing the upper bound on the length of the string that could match the regular expression provided. This length defaults to 128k. If the user needs to allow for matches beyond that size, then the maxPatternLength attribute should be set (in bytes); otherwise there is a risk that a potential match will be missed.
<is-file> and <is-directory>
...
<is-file path="${f0}"/>
<is-directory path="${f0}"/>
...
For a directory check, the existence check is included.
Object Evaluation
<boolean-expression>
This is just a variant on Expression or $E{...}. Provide the expression, without the surrounding $E, as the text of the element:
...
<boolean-expression>${i1} >= ${i0}</boolean-expression>
...
An exception will be thrown if the expression does not evaluate to a Boolean.
<equals>
Calls first.equals( second ). Either attribute can be set from the environment; in addition, there are primitiveAssignable variants for each (e.g., firstInt, secondDouble, etc.).
...
<equals firstInt="2" second="${i1}"/>
...
<is-a>
Equivalent to instanceof.
...
<is-a object="${comparableObject}" fqn="ncsa.tools.ogrescript.types.ComparableType"/>
<is-a object="${comparableObject}" typeObject="${object}"/>
...
The latter should always work; the former is not guaranteed to work when running inside of Eclipse.
<is-null>
...
<is-null object="${nullObject}"/>
...
Comparisons
The objects being compared are understood to implement the java.lang.Comparable interface; an exception will be thrown if they do not. These types all subclass Equals and thus have the same attributes as <equals>.
...
<greater-than firstInt="3" second="${i1}"/>
<greater-than-or-equal firstInt="3" secondInt="-3"/>
<less-than first="${i0}" second="${i1}"/>
<less-than-or-equal first="${i0}" secondInt="1"/>
...
Introspection
Object structure and content can be examined. For methods, a ncsa.tools.common.types.MethodPattern should be used:
...
<has-method fullScan="true">
<pattern target="${declareObject}">
<include>set*</include>
<parameter-type>java.net.URI</parameter-type>
</pattern>
</has-method>
...
There are lots of options on the MethodPattern; its attributes include the booleans nullParam, voidReturn, noExceptions, caseSensitive, inObjectMethods (include java.lang.Object in the search), along with numParams. Elements which can be used are:
exclude(for method name, takes an Ant-style pattern)excluded-exception-type(takes class name)excluded-return-type(takes class name)include(for method name, takes an Ant-style pattern)included-exception-type(takes class name)included-return-type(takes class name)parameter-type(takes class name; add these in order)strongly-excluded-modifier(takes Java modifier string)strongly-included-modifier(takes Java modifier string)weakly-excluded-modifier(takes Java modifier string)weakly-included-modifier(takes Java modifier string)
"Strong inclusion" means all must be satisfied (conjunction), "weak inclusion", at least one must be satisfied (disjunction), "strong exclusion" means at least one must not be satisfied, "weak exclusion", all must not be satisfied; "modifier" means Java modifiers (e.g., public, protected, static, final, etc.).
For fields, one can match field names, types and values (provided the field is directly visible); to check for null in the latter case, use isNull.
...
<has-field object="${declareObject}" name="configured"/>
<has-field object="${declareObject}" name="castTo" type="java.lang.String"/>
<!-- false, because cannot access protected member
<has-field object="${declareObject}" name="valueFromAttribute" intValue="2" failOnError="false"/>
-->
...
Note that an inaccessible field will not cause an exception to be thrown if failOnError is set to "false"; in the latter case, the type evaluates to false.
<matches>
The generalized matching evaluatable requires a ncsa.tools.common.Filter object; currently supported types (directly constructable as child elements) are ncsa.tools.common.ClassFilter, ncsa.tools.common.TypeFilter, and ncsa.tools.common.MatchFilter.
...
<matches toMatch="${declareObject}">
<class-filter typeFromString="ncsa.tools.ogrescript.tasks.core.Declare"/>
</matches>
...
Compound Evaluation (Statement)
This is pretty much what you would expect it to be:
Some examples:
<and>
<and>
<or>
<equals first="${s0}" second="4"/>
<equals first="${s0}" second="abcdefghijklmnop"/>
</or>
<matches string="${s1}" regexPattern=".*EF.*"/>
</and>
<or>
<or>
<equals first="${s0}" second="4"/>
<and>
<equals first="${s0}" second="abcdefghijklmnop"/>
<matches string="${s1}" regexPattern=".*EF.*"/>
</and>
</or>
<not> (and <x-or>)
<not>
<x-or>
<equals first="${s0}" second="4"/>
<equals first="${s0}" second="abcdefghijklmnop"/>
<equals first="${s0}" second="5"/>
<equals first="${s0}" second="abcdefgh"/>
<matches string="${s1}" regexPattern=".*EF.*"/>
</x-or>
</not>
Not is singleton; it will not perform De Morgan's rules automatically (in fact, if there is more than one child element, an exception will be thrown).
XOr means that one and only one of the conditions may be true.