Strict Standards: Declaration of action_plugin_include::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/include/action.php on line 20

Strict Standards: Declaration of action_plugin_tablewidth::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/tablewidth/action.php on line 107

Strict Standards: Declaration of action_plugin_source::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/source/action.php on line 99

Strict Standards: Declaration of action_plugin_indexmenu::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/indexmenu/action.php on line 169

Strict Standards: Declaration of action_plugin_uparrow::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/uparrow/action.php on line 69

Strict Standards: Declaration of action_plugin_feedmod::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/feedmod/action.php on line 133

Strict Standards: Declaration of action_plugin_tag::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/tag/action.php on line 117

Strict Standards: Declaration of action_plugin_blog::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/jwaresof/public_html/wiki/lib/plugins/blog/action.php on line 171

Strict Standards: Declaration of cache_instructions::retrieveCache() should be compatible with cache::retrieveCache($clean = true) in /home/jwaresof/public_html/wiki/inc/cache.php on line 289

Strict Standards: Only variables should be passed by reference in /home/jwaresof/public_html/wiki/doku.php on line 71
FAQ - JWare Free Software


   Has something about JWare/AntXtras Foundation (AntXtras) or this website made you curious, confused, annoyed, or bored? This section contains the answers to some Frequently Asked Questions about AntXtras and this website.

General Information

Q: What is JWare/AntXtras Foundation?

JWare/AntXtras Foundation (AntXtras) is a collection of free, general-purpose Ant extensions. The principal AntXtras components are described on the Overview page. You can also read the Top 10 reasons to use AntXtras.

Both AntXtras and its documentation are written for experienced Ant users and developers as its intent is to build on core Ant features. AntXtras is not intended for someone unfamiliar with Ant or for someone new to Ant.

Q: How is AntXtras licensed?

JWare/AntXtras Foundation, binary and source form, is released under the Free Software Foundation’s GNU LGPL 2.1. Please read the LGPL carefully before using any of the AntXtras source in your own application.

Q: What do I need to install to use AntXtras?

You need the version of Ant that matches the AntXtras series you’re downloading. The v1 series requires Ant 1.6.x; the v2 series requires Ant 1.7.0 or 1.7.1, and the v3 series requires Ant 1.8.0-1.8.4. Go to the Downloads page for detailed information.

Q: How do I report bugs, request features, etc.?

Go to the JWare Support page for a list of available project trackers. You can also subscribe to either of our two mailing lists: “AntX Announcements” and “AntX User Discussions”.

Q: What is JWare Software?

JWare Software (aka JWare) is the umbrella name of Sandbox Software MC’s open-source Java projects. The PURL for JWare software is

Q: What is Sandbox Software MC?

Sandbox Software MC is the moniker under which Simone Cato publishes various free and open software projects, articles, code snippets, etc. JWare refers to all the Java-related bits and it also sounds cooler than “SSMC”.

Q: Can I include a link to your website on my website?

You betcha! You an use either the URL” or “” as AntXtra’s home. Note that the top-level URL is a redirect to the based URL. You can also use a PURL: the PURL for AntXtras is (Complicated isn’t it?)

How do I...

Q: How do I <XYZ>...

All of our answers to frequently asked “How do I…” type questions are located in our How Tos section of this site. For an overview of all of our documentation for AntXtras, visit our Documents section.

Legacy Releases

Q: Hey! What happened to the <XYZ> component?

The AntXtras v2 series is a significant overhaul of the previous v1 (0.5.x) series. In particular, some AntXtras components where re-packaged into their own projects (for example most of the 0.5.x feedback components now live in the “Log4Ant” project), some components were removed because they have been superseded by built-in functionality, and some components were removed because they weren’t used very often or no longer provide much value.

The AntXtras v3 series shifted more elements from the core jar file to the advanced jar file; it also deprecated certain v1 component and parameter names in favor of their v2 or v3 replacements. Check the release notes of your package for breaking changes.

Build-Rules, Assertions

Q: What is the difference between an <assert> and a <fixturecheck>?

A <fixturecheck> is a special, target-independent, assertion (in the general sense of the word ‘target’). You use fixture checks to verify base script settings that are required for anything to work— including rule definitions and regular AntXtras assertions. It is because of this use of fixture checks to verify other assertions and rules that you cannot disable fixture checks like you can general assertions. The assumption is that if the fixture check fails, something fundamental is broken and your script cannot continue. Compared to other AntXtras validating tasks, fixture checks are very limited, so your Ant scripts should use regular AntXtras assertions whenever possible. Below is an example of how you might use a fixture check; the “required.sub-build.setup” rule requires the caller to define the oata.types property so we verify that this property exists using <fixturecheck>:

  <ruleset id="required.sub-build.setup">
     <fixturecheck isset="oata.types" message="The 'oata.types' property is defined"/>
     <require messageid="err.missing.copyfilters">
       <isreference name="copyfilters.sources"   class="${oata.types}.PatternSet"/>
       <isreference name="copyfilters.manifests" class="${oata.types}.PatternSet"/>
Q: Why do you redefine the <isset>, <available>, or [XYZ] condition?

AntXtras does not redefine any of the standard Ant conditions. However, not all standard Ant condition types are safe for concurrent use from multiple threads. When necessary to ensure that a kind-of condition is safe for multi-threaded use– as when used in AntXtras ruleset or tallyset definitions, AntXtras will provide multi-thread friendly alternatives. For example, as of Ant 1.5.3, a single <available> task is not safe for concurrent access from different threads. Well <available> is a serious work-horse in the Ant universe, so AntXtras supports the regular <available> condition but also provides a set of alternatives that are both safe to include in rules called concurrently from different threads and are single purposed. So instead of using <available> in a ruleset, you could use the more succinct and thread-safe AntXtras <isclass>, <isresource>, <isdirectory>, or <isfile> conditions. (Note that underneath AntXtras is still using the standard <available> function, we’ve just made it less verbose for common uses and usable in additional runtime environments.)

  <tallyset id="tally.j2se.apis">
    <isclass name="java.util.Iterator" trueproperty="atleast-j2se12-present"/>
    <isclass name="java.lang.StrictMath" trueproperty="atleast-j2se13-present"/>
    <isclass name="java.lang.AssertionError" trueproperty="atleast-j2se14-present"/>
    <isclass name="java.lang.Enum" trueproperty="atleast-j2se15-present"/>
Q: What is the difference between a <ruleset> and a <ruledef>?

Good question; these looks awfully similar on first glance. Some differences boil down to the history of AntXtras: the ruleset type pre-dates Ant macrodefs on which ruledefs are based. With Ant 1.5.x, the ruleset type was the best option available. With Ant 1.7.x and AntXtras 2.0.0, you would use a ruleset in two situations. First you can use a ruleset (or a tallyset) wherever an Ant condition is needed; for example, inside of a standard Ant <and> or <or> condition. You cannot do this with a ruledef. Second, you would use a ruleset when you need to use the same test (the ruleset) but to update different properties or variables with the result of each use; the example below shows how this would work. The Javadocs for the underlying Rule type also details additional differences that developers care about.

Personal Tools

Strict Standards: Only variables should be passed by reference in /home/jwaresof/public_html/wiki/doku.php on line 79