tasks, which perform operations on
many files, rely on nested tasks, and use multiple libraries (e.g.,
ejbjar task), require an in-depth
understanding of a task’s relationship with Ant.
Consider this a warning. This section delves into the dark and dirty
details involving the life cycle of a task. If you feel that your
custom tasks will not meet the complexity level described here, skip
this section and move on to our example. You can always come back and
read this section later. Understanding the engine and the task life
cycle is important for becoming an expert task writer, but it is not
a requirement for writing custom tasks that are relatively simple.
Ant processes all tasks identically. Ant sets attributes and processes nested elements at fixed intervals. We can predict how a task operates and design it accordingly. A task’s life can be broken down into two primary phases of time: parse-time and runtime. The parse-time phase begins when Ant reads the task from the XML (think of the engine as interpreting the XML, element by element). The runtime phase begins when the parse-time phase completes successfully.
Ant parses a task after its XML parser loads the element. The task’s name, attributes, and nested elements are wrapped into a single XML element object and stored in Ant’s in-memory DOM. During parse-time, operations can fail if the task XML is poorly formed or if actions taken within a task’s constructor throw ...