 |
“Strategies in (*)ability” | [iDareMedia] [JWare] [PET] [CI-Dashboard] |
|
“Strategies in (*)ability” | [iDareMedia] [JWare] [PET] [CI-Dashboard] |
What Is JWare?
JWare is the umbrella name of iDare Media Inc.'s open-source projects. We are diligently working on a public preview of the other JWare-based projects (to be hosted at http://www.jware.info). The PURL[?] for JWare is http://purl.net/jware/.
What is JWare/AntXtras Foundation?
JWare/AntXtras Foundation (AntX) is collection of free, general-purpose Ant extensions. The principal AntX components are described on the overview page and in the QuickStart Guide. JWare/AntXtras is released under the Free Software Foundation’s LGPL.
What do I need to install and use AntX?
In a nutshell, you need Ant (1.6.1 or later) and Log4j (1.2.3 or later). If you don't need the various feedback tasks (<emit> and friends), you can ignore the Log4J bits. See the download page for detailed information.
How do I report bugs, request features, etc.?
Visit the AntX Problems page for a list of available project artifact trackers. We also support two mailing lists: AntX Announcements and AntX User Discussions.
Can I include a link to your website in my website?
You betcha! BUT, remember that the URL “http://www.jware.info/AntXtras/” will eventually supercede “http://www.antxtras.info” as AntX's home. The antxtras.info top-level URL would then become a redirect to the jware.info based URL. (Complicated isn't it?) You can also use a PURL[?]. The PURL for AntX is http://purl.net/jware/antx/.
[Back to top]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). It is used to verify certain base script settings that must exist for anything to work— including rule definitions and regular AntX assertions. Compared to other AntX rule tasks, fixture checks are very limited, so your build scripts should use regular AntX assertions whenever possible. Below is an example of how we use <fixturecheck>; the “required.subbuild.fixture” rule would be really broken unless the ANTPATTERN property has been defined:
<rule id="required.subbuild.fixture">
<fixturecheck isset="ANTPATTERN">
<require msgid="err.misin.filters">
<isreference name="copyfilters.sources" class="${ANTPATTERN}"/>
<isreference name="copyfilters.manifests" class="${ANTPATTERN}"/>
</require>
</rule>
Why can't I nest AntX conditions inside the <and>, <not>, etc.?
Before Ant 1.6, the standard <condition> operator sub-elements only understand the predefined Ant conditions and there's nothing AntX can do to dynamically expand that set. If you cannot upgrade to Ant 1.6 (best solution), one work-around for the limitations of <and> and <or> issue, is to use the AntX <tally> task which understands both the standard Ant conditions and the AntX conditions. For instance, to use AntX conditions inside an <and> or <or> operation, you could write:
<tally logic="and">
<tally logic="or">
<issettrue property="junit.present"/>
<issettrue property="pet.present"/>
</tally>
<isnotwhitespace property="module_id"/>
<isnumeric property="build.number" gt="0"/>
</tally>
There is no AntX substitute for the standard <not> operator. You could either use some sort-of (creative) combination of the property-setting functionality of conditions and the AntX <isnotset> condition, or the multi-set conditions <anyset>, <noneset>, and <allset>.
Why does AntX redefine the <isset>, <available>, or [XYZ] condition?
AntX does not redefine any of the standard Ant conditions. Where necessary AntX has provided rule-friendly alternatives to certain conditions to ensure that kind-of condition is safe for use in shareable AntX build rules. For example, as of 1.5.3, a single <available> task isn't safe for concurrent access from different threads. Well <available> is a serious work-horse in the build script universe, so AntX supports the regular <available> condition and provides a set of alternatives that are both safe to include in rules called concurrently from different threads, and are single purposed (and therefore more human-readable IMHO).
[Back to top]Is AntX’s <emit> and friends the same as “log4Ant”?
Yes. We needed a short (ok memorable) name to post on the Log4J website under the log4j “Ports” section. Our AntX feedback components are a complete bridge from Ant to Log4j so they really are “log4Ant”.
Will an <emitlogs> capture information broadcast with <emit>?
Maybe. The <emitlogs> task captures every logged Ant message and copies it (as in “cc:”) to an external logging system. If you tell your <emit> task to echo to the Ant logging system, then yes the message will be captured by an enclosing <emitlogs> (and effectively registered twice with the external logging system).
In Log4J, how do I render the ErrorSnapshot object sometimes broadcast by <emit>?
If/when a build failure occurs, the <emit> task ensures that context and specific fault information is passed on to the logging system using an object called an “ErrorSnapshot”. AntX has provided a custom Log4J ObjectRenderer to ensure these snapshot objects are translated properly for any Log4J Appender (the basis of any Log4J viewing system). (This custom renderer isn't absolutely necessary, the error snapshots can produce a usable string on their own as expected by the default object renderer. However, custom information like captured properties and task or target information will not be included.) Below are some configuration lines to include in two Log4j configuration file-types to map ErrorSnapshots to the custom object renderer:
For a “log4j.properties” file:
log4j.renderer.com.idaremedia.antx.ErrorSnapshot=\
com.idaremedia.antx.feedback.ErrorSnapshotRenderer
For a “log4j.xml” file:
<renderer renderedClass="com.idaremedia.antx.ErrorSnapshot"
renderingClass="com.idaremedia.antx.feedback.ErrorSnapshotRenderer">
How do I support the “XYZ” logging system with AntX?
By default the feedback package classes work with the Log4J logging system, but it takes just three steps to customize the feedback tasks to use other logging systems like the J2SE 1.4's logging system or IBM's JLog.
Why doesn't <emit> pick up my <printer> settings for references?
The short answer is that printer mappings (<printer>) are only used by the <print> task. Now the long answer: Printer mappings are used to associated your custom datatype printers (called “display strategies” in AntX developer-speak) with the <print> command. Printers can be as simple or as complex as you want them to be; they're your diagnostic dump tool. The <emit> task on the other hand, wants to broadcast thorough but focused bits of information so it uses the simpliest data string form it can. For most standard data types, this short-form is obvious; for example, a <patternset> would send its pattern strings while a <fileset> would send its list of included files. [Update: Starting with AntX 0.4, you can assign a printer to a reference datatype if there is not other object renderer installed.]
[Back to top]