<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>&nbsp;</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 &quot;core&quot; 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 &quot;build&quot; has 
  a name of &quot;prop3&quot;, however its &quot;fully-qualified&quot; name is 
  /root/build/prop3. The root of a Task execution list is &quot;/&quot; 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 
  &quot;../sibling&quot;. It would be more convenient to not require the &quot;../&quot;. 
  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 &quot;directory-name.mf&quot;. 
  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 &quot;core&quot; 
  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 &quot;runtime&quot; 
  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 &#151; <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:jimcook@visualxs.com">Jim Cook</a><br>
  <a href="http://www.visualxs.com/">Visual XS</a></p>
</body>
</html>