donaldp 00/12/18 06:33:46
Added: proposal/frantic/website Task.html index.html
proposal/frantic/website/images frantic_logo.gif
task_hierarchy.gif
Log:
oops - forgot to add contents of directory ;)
Revision Changes Path
1.1 jakarta-ant/proposal/frantic/website/Task.html
Index: Task.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd";>
<!--NewPage-->
<HTML>
<HEAD>
<!-- Generated by javadoc on Sat Dec 16 22:19:46 EST 2000 -->
<TITLE>
: Interface Task
</TITLE>
<LINK REL ="stylesheet" TYPE="text/css" HREF="../../../../stylesheet.css"
TITLE="Style">
</HEAD>
<BODY BGCOLOR="white">
<!-- ========== START OF NAVBAR ========== -->
<A NAME="navbar_top"><!-- --></A>
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_top_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">
<TR ALIGN="center" VALIGN="top">
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT
CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../overview-tree.html"><FONT
CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../deprecated-list.html"><FONT
CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../index-all.html"><FONT
CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../help-doc.html"><FONT
CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
</TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
</EM>
</TD>
</TR>
<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
PREV CLASS
NEXT CLASS</FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../../../index.html" TARGET="_top"><B>FRAMES</B></A>
<A HREF="Task.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
SUMMARY: INNER | <A
HREF="#field_summary">FIELD</A> | CONSTR | <A
HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: <A
HREF="#field_detail">FIELD</A> | CONSTR | <A
HREF="#method_detail">METHOD</A></FONT></TD>
</TR>
</TABLE>
<!-- =========== END OF NAVBAR =========== -->
<HR>
<!-- ======== START OF CLASS DATA ======== -->
<H2>
<FONT SIZE="-1">
org.apache.ant.tasks</FONT>
<BR>
Interface Task</H2>
<HR>
<DL>
<DT>public interface <B>Task</B></DL>
<P>
Task is the core interface for all structures that will be processed by the
TaskEngine.
<P>
<HR>
<P>
<!-- ======== INNER CLASS SUMMARY ======== -->
<!-- =========== FIELD SUMMARY =========== -->
<A NAME="field_summary"><!-- --></A>
<TABLE BORDER="1" CELLPADDING="3" CELLSPACING="0" WIDTH="100%">
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
<TD COLSPAN=2><FONT SIZE="+2">
<B>Field Summary</B></FONT></TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE>static int</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#EXECUTION_MODE_EXPLICIT">EXECUTION_MODE_EXPLICIT</A></B></CODE>
<BR>
</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE>static int</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#EXECUTION_MODE_IMPLICIT">EXECUTION_MODE_IMPLICIT</A></B></CODE>
<BR>
</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE>static int</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#EXECUTION_MODE_PRIORITY">EXECUTION_MODE_PRIORITY</A></B></CODE>
<BR>
</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE>static char</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#NAME_SEPARATOR">NAME_SEPARATOR</A></B></CODE>
<BR>
</TD>
</TR>
</TABLE>
<!-- ======== CONSTRUCTOR SUMMARY ======== -->
<!-- ========== METHOD SUMMARY =========== -->
<A NAME="method_summary"><!-- --></A>
<TABLE BORDER="1" CELLPADDING="3" CELLSPACING="0" WIDTH="100%">
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
<TD COLSPAN=2><FONT SIZE="+2">
<B>Method Summary</B></FONT></TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> void</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#execute(org.apache.ant.engine.TaskEngine)">execute</A></B>(org.apache.ant.engine.TaskEngine engine)</CODE>
<BR>
Causes the
existing Task implementation to execute.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> java.lang.String</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getAttributeValue(java.lang.String)">getAttributeValue</A></B>(java.lang.String name)</CODE>
<BR>
Each Task will
hold its attributes in some manner.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> <A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A>[]</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getChildren()">getChildren</A></B>()</CODE>
<BR>
Returns the an
array of Task objects that are subordinate to this Task.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> int</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getExecutionMode()">getExecutionMode</A></B>()</CODE>
<BR>
Determines
whether this Task is executed whenever its parent is executed,
or if its execution must be specifically requested.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> java.lang.String</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getFullyQualifiedName()">getFullyQualifiedName</A></B>()</CODE>
<BR>
The
"fully-qualified" name of a Task is the Task's name, prepended by its
parent's name, prepended by its parent's name, etc.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> <A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A></CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getParent()">getParent</A></B>()</CODE>
<BR>
Returns this
Task's parent Task.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> <A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A></CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getRootTask()">getRootTask</A></B>()</CODE>
<BR>
Proceed backwards
through the nodes until we come across the first Task
in the tree.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> <A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A></CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getTask(java.lang.String)">getTask</A></B>(java.lang.String taskPath)</CODE>
<BR>
A mechanism for
locating a task relative to the current task.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> java.lang.String</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#getTaskName()">getTaskName</A></B>()</CODE>
<BR>
Just a simple
name used to identify a Task.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> void</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#init(org.apache.ant.engine.TaskEngine)">init</A></B>(org.apache.ant.engine.TaskEngine engine)</CODE>
<BR>
Called when the
Task first gets "noticed" by the TaskEngine.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> boolean</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#isPropertyContainer()">isPropertyContainer</A></B>()</CODE>
<BR>
Determines
whether a Task is suitable for holding property values.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> void</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#setParent(org.apache.ant.tasks.Task)">setParent</A></B>(<A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A> parent)</CODE>
<BR>
Sets the Task's
parent.</TD>
</TR>
<TR BGCOLOR="white" CLASS="TableRowColor">
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
<CODE> void</CODE></FONT></TD>
<TD><CODE><B><A
HREF="../../../../org/apache/ant/tasks/Task.html#validate()">validate</A></B>()</CODE>
<BR>
Each Task should
have the ability to validate its state.</TD>
</TR>
</TABLE>
<P>
<!-- ============ FIELD DETAIL =========== -->
<A NAME="field_detail"><!-- --></A>
<TABLE BORDER="1" CELLPADDING="3" CELLSPACING="0" WIDTH="100%">
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
<TD COLSPAN=1><FONT SIZE="+2">
<B>Field Detail</B></FONT></TD>
</TR>
</TABLE>
<A NAME="EXECUTION_MODE_IMPLICIT"><!-- --></A><H3>
EXECUTION_MODE_IMPLICIT</H3>
<PRE>
public static final int <B>EXECUTION_MODE_IMPLICIT</B></PRE>
<DL>
</DL>
<HR>
<A NAME="EXECUTION_MODE_EXPLICIT"><!-- --></A><H3>
EXECUTION_MODE_EXPLICIT</H3>
<PRE>
public static final int <B>EXECUTION_MODE_EXPLICIT</B></PRE>
<DL>
</DL>
<HR>
<A NAME="EXECUTION_MODE_PRIORITY"><!-- --></A><H3>
EXECUTION_MODE_PRIORITY</H3>
<PRE>
public static final int <B>EXECUTION_MODE_PRIORITY</B></PRE>
<DL>
</DL>
<HR>
<A NAME="NAME_SEPARATOR"><!-- --></A><H3>
NAME_SEPARATOR</H3>
<PRE>
public static final char <B>NAME_SEPARATOR</B></PRE>
<DL>
</DL>
<!-- ========= CONSTRUCTOR DETAIL ======== -->
<!-- ============ METHOD DETAIL ========== -->
<A NAME="method_detail"><!-- --></A>
<TABLE BORDER="1" CELLPADDING="3" CELLSPACING="0" WIDTH="100%">
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
<TD COLSPAN=1><FONT SIZE="+2">
<B>Method Detail</B></FONT></TD>
</TR>
</TABLE>
<A NAME="execute(org.apache.ant.engine.TaskEngine)"><!-- --></A><H3>
execute</H3>
<PRE>
public void <B>execute</B>(org.apache.ant.engine.TaskEngine engine)
throws org.apache.ant.AntException</PRE>
<DL>
<DD>Causes the existing Task implementation to execute.</DL>
<HR>
<A NAME="init(org.apache.ant.engine.TaskEngine)"><!-- --></A><H3>
init</H3>
<PRE>
public void <B>init</B>(org.apache.ant.engine.TaskEngine engine)
throws org.apache.ant.AntException</PRE>
<DL>
<DD>Called when the Task first gets "noticed" by the TaskEngine.</DL>
<HR>
<A NAME="validate()"><!-- --></A><H3>
validate</H3>
<PRE>
public void <B>validate</B>()
throws org.apache.ant.AntException</PRE>
<DL>
<DD>Each Task should have the ability to validate its state. This would be
invoked by the TaskEngine prior to commencing an execution cycle.</DL>
<HR>
<A NAME="getTaskName()"><!-- --></A><H3>
getTaskName</H3>
<PRE>
public java.lang.String <B>getTaskName</B>()</PRE>
<DL>
<DD>Just a simple name used to identify a Task. This name is only sufficient
for simple debugging and GUI output. It does not uniquely identify a
Task.<DD><DL>
<DT><B>See Also: </B><DD><A
HREF="../../../../org/apache/ant/tasks/Task.html#getFullyQualifiedName()"><CODE>getFullyQualifiedName()</CODE></A></DL>
</DD>
</DL>
<HR>
<A NAME="getTask(java.lang.String)"><!-- --></A><H3>
getTask</H3>
<PRE>
public <A HREF="../../../../org/apache/ant/tasks/Task.html">Task</A>
<B>getTask</B>(java.lang.String taskPath)</PRE>
<DL>
<DD>A mechanism for locating a task relative to the current task. This
navigation sceme will mimic a typical OS system. '..' will move back
a level in the Task tree. If taskPath begins with '/' then the root node
will be used as a starting point.
<p></p>
Returns null of no task is found at this location.</DL>
<HR>
<A NAME="getRootTask()"><!-- --></A><H3>
getRootTask</H3>
<PRE>
public <A HREF="../../../../org/apache/ant/tasks/Task.html">Task</A>
<B>getRootTask</B>()</PRE>
<DL>
<DD>Proceed backwards through the nodes until we come across the first Task
in the tree. This is the root Task.</DL>
<HR>
<A NAME="getFullyQualifiedName()"><!-- --></A><H3>
getFullyQualifiedName</H3>
<PRE>
public java.lang.String <B>getFullyQualifiedName</B>()</PRE>
<DL>
<DD>The "fully-qualified" name of a Task is the Task's name, prepended by its
parent's name, prepended by its parent's name, etc. This method may be
used by the Task's hashCode() method to calculate a hash that will
uniquely identify a Task.</DL>
<HR>
<A NAME="getExecutionMode()"><!-- --></A><H3>
getExecutionMode</H3>
<PRE>
public int <B>getExecutionMode</B>()</PRE>
<DL>
<DD>Determines whether this Task is executed whenever its parent is executed,
or if its execution must be specifically requested.
<p></p>
<dl><dt>EXECUTION_MODE_EXPLICIT</dt>
<dd>Requires interaction by the TaskEngine in order to execute.</dd>
<dt>EXECUTION_MODE_IMPLICIT</dt>
<dd>This Task is automatically executed when its parent is
executed.</dd>
<dt>EXECUTION_MODE_PRIORITY</dt>
<dd>These Tasks are executed prior to its parent's execution</dd></dl>
<p></p>
The default mode should probably be EXECUTION_MODE_IMPLICIT. In the
build domain of Ant, every Task below a Task will normally be executed.
The major exception to this is the Target. When a Project Task is
executed, all Target Tasks do <i>not</i> automatically fire, however all
Property Tasks <i>do</i> execute.</DL>
<HR>
<A NAME="isPropertyContainer()"><!-- --></A><H3>
isPropertyContainer</H3>
<PRE>
public boolean <B>isPropertyContainer</B>()</PRE>
<DL>
<DD>Determines whether a Task is suitable for holding property values.</DL>
<HR>
<A NAME="getAttributeValue(java.lang.String)"><!-- --></A><H3>
getAttributeValue</H3>
<PRE>
public java.lang.String
<B>getAttributeValue</B>(java.lang.String name)</PRE>
<DL>
<DD>Each Task will hold its attributes in some manner. This method will allow
the Task implementation to return the value of its attribute.</DL>
<HR>
<A NAME="getParent()"><!-- --></A><H3>
getParent</H3>
<PRE>
public <A HREF="../../../../org/apache/ant/tasks/Task.html">Task</A>
<B>getParent</B>()</PRE>
<DL>
<DD>Returns this Task's parent Task. If this Task is the root Task, then this
method will return null.</DL>
<HR>
<A NAME="setParent(org.apache.ant.tasks.Task)"><!-- --></A><H3>
setParent</H3>
<PRE>
public void <B>setParent</B>(<A
HREF="../../../../org/apache/ant/tasks/Task.html">Task</A> parent)</PRE>
<DL>
<DD>Sets the Task's parent.</DL>
<HR>
<A NAME="getChildren()"><!-- --></A><H3>
getChildren</H3>
<PRE>
public <A HREF="../../../../org/apache/ant/tasks/Task.html">Task</A>[]
<B>getChildren</B>()</PRE>
<DL>
<DD>Returns the an array of Task objects that are subordinate to this
Task.</DL>
<!-- ========= END OF CLASS DATA ========= -->
<HR>
<!-- ========== START OF NAVBAR ========== -->
<A NAME="navbar_bottom"><!-- --></A>
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_bottom_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">
<TR ALIGN="center" VALIGN="top">
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT
CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../overview-tree.html"><FONT
CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../deprecated-list.html"><FONT
CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../index-all.html"><FONT
CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A
HREF="../../../../help-doc.html"><FONT
CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
</TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
</EM>
</TD>
</TR>
<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
PREV CLASS
NEXT CLASS</FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../../../index.html" TARGET="_top"><B>FRAMES</B></A>
<A HREF="Task.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
SUMMARY: INNER | <A
HREF="#field_summary">FIELD</A> | CONSTR | <A
HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: <A
HREF="#field_detail">FIELD</A> | CONSTR | <A
HREF="#method_detail">METHOD</A></FONT></TD>
</TR>
</TABLE>
<!-- =========== END OF NAVBAR =========== -->
<HR>
</BODY>
</HTML>
1.1 jakarta-ant/proposal/frantic/website/index.html
Index: index.html
===================================================================
<html>
<head>
<title>Ant Proposal - Frantic</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
<!--
.quote { font-family: "Times New Roman", Times, serif; font-size: 24pt}
p { font-family: Verdana, Arial, Helvetica, sans-serif}
h1 { font-family: "Times New Roman", Times, serif; color: #330099;
font-weight: bold}
h2 { font-family: Verdana, Arial, Helvetica, sans-serif; color: #3300CC}
h3 { font-family: Arial, Helvetica, sans-serif; font-weight: bold; color:
#3300CC}
a { text-decoration: none; color: #9900FF}
a:hover { text-decoration: underline}
h5 { font-family: Verdana, Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body bgcolor="#FFFFFF">
<h1 align="center"><img src="images/frantic_logo.gif" width="250"
height="264" align="left">Ant
2.0 Proposal</h1>
<h2 align="center">Code Name - Frantic</h2>
<p>Frantic hardly describes the proposal process...more like my coding and
design
efforts! I am relatively new to Ant and the mail list, and I have posted
several
emails recently regarding the use of DOM in the future of Ant. Once I
discovered
the mail archive (thanks Simeon), I had a chance to notice that many of my
questions
were asked before. My extemporaneous emails were not without consequence it
seems. After writing one of them it set some wheels in motion for what I
hope
is a useful addition to the current (and growing) number of proposals for
Ant
2.0.</p>
<center>
<table width="50%" border="0" bgcolor="#9933FF" cellpadding="1"
cellspacing="0">
<tr>
<td>
<table width="100%" border="0" cellpadding="4">
<tr bgcolor="#CCCCFF" align="center">
<td>
<p>I think the concept behind Ant should be changed to be a
"Task
Execution Engine", and the concept of Project and Target can
be
generalized into a specific form of a Task.</p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</center>
<p> </p>
<p>The email list has received some requests from developers to extend Ant to
support different problem domains. Peter Donald has latched onto this issue
and I understand that he has incorporated some of these ideas into his Ant
proposal.
I also have seen some very impressive DOM support integrated into Antidote,
an elegant basis for a GUI editor crafted by Simeon Fitch. Sim achieves a
great
deal of flexibility by using the W3C DOM as a superclass to his
Project/Target/Task
objects. He has, in effect, abstracted each of these "core" Ant
objects
until they are simply DOM nodes.</p>
<p>Peter's and Sim's ideas struck a chord and I thought that Peter's desire
to
allow Ant to break free from the Build domain and into Install domains by
extending
Ant, could be achieved by looking at the problem from a different point of
view.
As I stated in my email, we can achieve a much higher degree of flexibility
in Ant by generalizing more.</p>
<h3>Design Proposal</h3>
<p>I believe that Ant 2.0 should be re-termed a <b><i>Task Execution
Engine</i></b>,
and the core of Ant becomes the Engine and the Task. This seems a little
radical
considering that the Project/Target/Task object model has served us so well
in Ant 1.x, however it is very clear that Project and Target are simple
another
type of Task.</p>
<p>An enormous amount of code has been added to maintain Project and Target
as
separate classes with distinct, hard-coded behaviors. From the
proof-of-concept
code that I have been developing, I am inspired by how much more elegant
the
code becomes when this simplified model is realized. </p>
<p>Having a base Task interface that all Tasks implement will also offer a
generalized
approach that benefits GUI's in much the same manner that the DOM has
helped
Antidote. Also, by making Task an interface instead of a class, we can
finally
free ourselves of implementation specifics.</p>
<p>As I was writing the concept code, it struck me that I was too worried
about
the XML. Simeon Fitch mentioned in an email in early December, the
possibility
of storing build scripts in a database. I think this, along with various
comments
about DOM dependencies from Peter Donald, Jose Alberto Fernandez, and
Stefan
Bodewig made me realize that Core Ant shouldn't care where the build script
lives or in which format it is stored. It is the object model that is
primarily
important.</p>
<h3>The Task</h3>
<p>The cornerstone of this proposal hinges on the <a href="Task.html"
target="new">Task</a>
Interface. It is the only type of external object that the Execution Engine
knows how to handle. It is in this simplicity that the most powerful Ant
can
be realized.</p>
<p>The Task is an object that is aware of it's place in ahierarchy. To this
end
it is aware of its parent and its children. Please note that this is a
runtime
dependency and a scripting language (or the Task itself) can dynamically
change
the relationship of Tasks.</p>
<table border="0" align="left">
<tr>
<td><img src="images/task_hierarchy.gif" width="200" height="140"></td>
</tr>
<tr align="center">
<td>
<h5><i>Figure 1</i></h5>
</td>
</tr>
</table>
<p>Key to being able to manipulate Tasks at runtime is some sort of naming
conventions.
Currently in the Frantic design is the concept of a Task name. Tasks, being
hierarchical, can be thought of as a directory structure (see figure 1). If
each Task is assigned a name that is unique among its siblings, we can then
have a powerful means of locating and referencing a particular Task
anywhere
in the hierarchy. </p>
<p>For example, the Property Task below the Target named "build"
has
a name of "prop3", however its "fully-qualified" name
is
/root/build/prop3. The root of a Task execution list is "/" and
the
tag name, in our example /root. In the concept source code I use this
principal
of hierarchical naming to support dependencies. Currently, I am treating
these
Task names as directories and not as files. This should perhaps change
slightly
to the filename approach. In the directory-based approach, a sibling is
named
"../sibling". It would be more convenient to not require the
"../".
In fact, I think I have convinced myself of this.</p>
<h3> Task Discovery</h3>
<p>I haven't coded this portion, however I plan on basing it on Duncan's idea
of using the Jar manifests to locate and identify tasks on the classpath. I
was first exposed to this technique in the OpenTools API of Borland's
JBuilder
IDE, and I have since used it on a large project for a consulting
customer.</p>
<p>The classpath is scanned at runtime to locate all directories and jar
files.
These directories and jar files will have a manifest file that will contain
manifest entries that serve to tie a string token to the Task
implementation
class responsible for that token. Directories cannot have manifests per se,
but we will utilize a file, one-level up from the directory, with a name
"directory-name.mf".
This file will be in the format of a manifest file. This will allow
developers
to create and test new Tasks without the burden of having to make a Jar
archive
every time.</p>
<h3>Attribute Validation</h3>
<p>Brett McLaughlin introduced a very interesting techique to perform object
validation
using XML Schema in a series of <a
href="http://www.javaworld.com/javaworld/jw-09-2000/jw-0908-validation.html";>JavaWorld
articles</a>. I can see this technique applied to Tasks as well. The user
could
include a schema with a special name in the jar file that accompanies the
Tasks.
This schema could be used at runtime to validate a Task's attributes.</p>
<p>I would imagine that this feature would be outside of what is considered
"core"
Ant.</p>
<h3>The Execution Engine</h3>
<p>The engine only knows how to process Task objects, and that is what makes
it
extremely efficient. It is modeled after how I believe a compiler, or
command
interpreter would function. It contains a call stack which I call a
<i><b>task
stack</b></i>, and this task stack is under complete control of the engine.
This is not to say that Tasks cannot manipulate the task stack at runtime,
because
they do. However, all of this access takes place under the watchful eye of
the
execution engine. </p>
<h3>Properties</h3>
<p>Keeping track of properties is closely tied to the execution engine, and I
modeled it in a manner consistent with how I believe compilers must work. I
use the concept of a hierarchical series of hashtables that support the
concept
of scope in property lists.</p>
<p>I had originally put the concept of a property into a Task and completely
implemented
the bugger. It turned out during testing that my logic was flawed. It
seemed
to work well at first...a property defined in a Task would be available to
all
child Tasks, but unavailable to any ancestors. When a Task requested the
latest
data on a property, it would look in its property list. If it wasn't found
there,
it would look in its parent's list, and so on. Instant scope.</p>
<p>However, it became quickly apparent that properties are a
"runtime"
consideration. This is something that Jose Alberto Fernandez will not let
any
of us forget for long. :-) What I needed was to move this hierarchical
chain
of property lists into the engine. For each new Task executed, a new
property
list is created and also pushed onto the stack. It seems to work like a
champ.</p>
<p>I also coded up key substitution into the getParameterValue() events. They
seem to work fine, although I haven't worked up enough test cases to be
sure.</p>
<p>One additional cool feature is that parameters need not only hold Strings.
I thought that there would be occasions where properties will hold Tasks as
well. I believe this will turn out to be a prime mechanism for creating
reference
id Tasks like the current FileSet objects and referring to them in other
Tasks
just as you would any property value.</p>
<h3>Attributes</h3>
<p>I haven't spent any time addresing what is currently referred to a Task's
attributes
in Ant 1.x. I still need to think about this concept some more, but as I
dwell
on what an attribute is, I keep coming back to the properties. Just like a
property
functions as a scoped variable, an attribute is the same thing. Albeit, its
scope is limited to the Task that uses it, but so what.</p>
<h3>Execution Events</h3>
<p>The execution engine also supports a few key events that can occur during
the
execution lifecycle. Currently events exist for execution start/finish,
task
start/execute/finish, exceptions, and simple messaging. The messaging event
allows Tasks to communicate in a standard way that will leverage the
engine's
event system to allow various front-ends to intelligently and appropriately
process the output.</p>
<h3>Scripting</h3>
<p>I have no experience with incorporating a scripting engine into an engine,
but I do know that this proposal should address the primary issues that
surround
such an integration. I think that two features which are absolutely
essential
are:</p>
<p> Provide some sort of naming convention such that a particular Task can be
found given an absolute name or a name relative to another Task. This is
complete
and working in the concept code.</p>
<p>Leave all decisions regarding property evaluation and Task's knowledge of
these
properties until the last possible moment.</p>
<h3>Recursive Tasks</h3>
<p>I realize that Ant 1.x spent some clock cycles dedicated to resolving
circular
references in the Task definitions. I didn't spend any time on that
intentionally.
I am not so sure that the elimination of circular references is a good
idea.
Especially moving forward, with the incorporation of a scripting language,
I
can envision Tasks the assembler wants to execute repeatedly, perhaps even
recursively.
I think we should treat this the same way that any modern computer language
would — <i>caveat emptor</i>.</p>
<h3>Summary</h3>
<p>There is a lot more to do with this proposal and the concept code. It has
been
an exciting weekend getting these thoughts down and trying to back them up.
I look forward to collaborating with others on the list if they wish to
help
me, even though I am in proposal phase. I certainly don't know much about
XML
parsing and I could use some ideas on how to further my starting model. I
would
love to show the Ant core model built in a Builder agnostic manner.
Basically,
I want XML to be an option, not a requirement.</p>
<p>I would also be interested in perhaps building an adapter task that will
allow
Ant 1.x tasks to be reused unchanged in the Frantic proposal. The concept
of
a Task hasn't changed much, so perhaps this is a possibility.</p>
<p>As always, your feedback is welcome. I expect that I have missed some
major
holes and I would like the opportunity to work with others to plug them
up!</p>
<p><a href="mailto:[EMAIL PROTECTED]">Jim Cook</a><br>
<a href="http://www.visualxs.com/";>Visual XS</a></p>
</body>
</html>
1.1
jakarta-ant/proposal/frantic/website/images/frantic_logo.gif
<<Binary file>>
1.1
jakarta-ant/proposal/frantic/website/images/task_hierarchy.gif
<<Binary file>>
