The main script-facing conditions are: StringEquals(<equals>), AllSet(<allset>), NoneSet(<noneset>), AnySet(<anyset>), IsAntVersion(<antversion>), Matches(<matches>), IsNumeric(<isnumeric>), IsNotWhitespace(<isnotwhitespace>), and IsBoolean(<isboolean>).
There are two categories of AntX conditions: "short hand" adapters for existing Ant conditions like <available>, and new original AntX conditions for which there is no existing Ant complement. The AntX short hand wrappers are mostly there to minimize (and clarify) the script necessary to include standard Ant conditions in both AntX assertions and tallies. However, some extensions like IsSet and IsReference, replace standard AntX conditions with more powerful variants that work better within the AntX build rules framework. AntX condition classes are named so that their leaf names reflect the condition they define; the term 'Condition' should not appear in the leaf name.
Every single-value AntX condition subclasses from the base FlexCondition. FlexCondition enables AntX conditions to support "Flexible Value Substitution" as described in the "Quick Start Guide". A flex condition's source value can be a literal, a property, a variable, or a reference (stringified). Multi-value AntX conditions all derive from the CheckSetCondition class; individual items nested inside a multi-value condition also support flexible value substitution.
AntX conditions rely heavily on the common parameter interfaces to define common options. These enables our condition-using components to work in terms of interfaces instead of specific condition classes. If a rule task supports "short hand" conditions (all condition information is defined in terms of attribute parameters instead of nested elements), it should probably implement the ShortHandConditions interface. A helper class ShortHandHelper embodies the default AntX implementation of this interface; your task class can simply delegate to an internal instance.
AntX 0.5 introduced "Value URIs" and generic criteria support in its flow control tasks. Value URIs let you access all kinds of fixture information other than properties. The ShortHandValueURIHandler lets you plug (most) short hand conditions into this system. You no longer have to define independent conditions for simple tests (embodied by a single condition) or create extraneous properties to determine whether a criteria for task execution has been met.