Ant
+ 2.0 Proposal
+
+
|
++ + | +||||||
| + PREV CLASS + NEXT CLASS | ++ FRAMES + NO FRAMES | +||||||
| + SUMMARY: INNER | FIELD | CONSTR | METHOD | ++DETAIL: FIELD | CONSTR | METHOD | +||||||
+Task is the core interface for all structures that will be processed by the + TaskEngine. +
+
| +Field Summary | +|
+static int |
+EXECUTION_MODE_EXPLICIT
+
++ |
+
+static int |
+EXECUTION_MODE_IMPLICIT
+
++ |
+
+static int |
+EXECUTION_MODE_PRIORITY
+
++ |
+
+static char |
+NAME_SEPARATOR
+
++ |
+
| +Method Summary | +|
+ void |
+execute(org.apache.ant.engine.TaskEngine engine)
+
++ Causes the existing Task implementation to execute. |
+
+ java.lang.String |
+getAttributeValue(java.lang.String name)
+
++ Each Task will hold its attributes in some manner. |
+
+ Task[] |
+getChildren()
+
++ Returns the an array of Task objects that are subordinate to this Task. |
+
+ int |
+getExecutionMode()
+
++ Determines whether this Task is executed whenever its parent is executed, + or if its execution must be specifically requested. |
+
+ java.lang.String |
+getFullyQualifiedName()
+
++ 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. |
+
+ Task |
+getParent()
+
++ Returns this Task's parent Task. |
+
+ Task |
+getRootTask()
+
++ Proceed backwards through the nodes until we come across the first Task + in the tree. |
+
+ Task |
+getTask(java.lang.String taskPath)
+
++ A mechanism for locating a task relative to the current task. |
+
+ java.lang.String |
+getTaskName()
+
++ Just a simple name used to identify a Task. |
+
+ void |
+init(org.apache.ant.engine.TaskEngine engine)
+
++ Called when the Task first gets "noticed" by the TaskEngine. |
+
+ boolean |
+isPropertyContainer()
+
++ Determines whether a Task is suitable for holding property values. |
+
+ void |
+setParent(Task parent)
+
++ Sets the Task's parent. |
+
+ void |
+validate()
+
++ Each Task should have the ability to validate its state. |
+
| +Field Detail | +
+public static final int EXECUTION_MODE_IMPLICIT+
+public static final int EXECUTION_MODE_EXPLICIT+
+public static final int EXECUTION_MODE_PRIORITY+
+public static final char NAME_SEPARATOR+
| +Method Detail | +
+public void execute(org.apache.ant.engine.TaskEngine engine) + throws org.apache.ant.AntException+
+public void init(org.apache.ant.engine.TaskEngine engine) + throws org.apache.ant.AntException+
+public void validate() + throws org.apache.ant.AntException+
+public java.lang.String getTaskName()+
getFullyQualifiedName()+public Task getTask(java.lang.String taskPath)+
+public Task getRootTask()+
+public java.lang.String getFullyQualifiedName()+
+public int getExecutionMode()+
+public boolean isPropertyContainer()+
+public java.lang.String getAttributeValue(java.lang.String name)+
+public Task getParent()+
+public void setParent(Task parent)+
+public Task[] getChildren()+
+
+
|
++ + | +||||||
| + PREV CLASS + NEXT CLASS | ++ FRAMES + NO FRAMES | +||||||
| + SUMMARY: INNER | FIELD | CONSTR | METHOD | ++DETAIL: FIELD | CONSTR | METHOD | +||||||
Ant
+ 2.0 ProposalFrantic 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.
+
+
|
+
+
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.
+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.
+I believe that Ant 2.0 should be re-termed a Task Execution Engine, + 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.
+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.
+ +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.
+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.
+The cornerstone of this proposal hinges on the Task + 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.
+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.
+ |
+
+ Figure 1+ |
+
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.
+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.
+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.
+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.
+Brett McLaughlin introduced a very interesting techique to perform object validation + using XML Schema in a series of JavaWorld + articles. 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.
+I would imagine that this feature would be outside of what is considered "core" + Ant.
+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 task + stack, 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.
+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.
+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.
+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.
+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.
+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.
+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.
+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.
+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:
+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.
+Leave all decisions regarding property evaluation and Task's knowledge of these + properties until the last possible moment.
+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 — caveat emptor.
+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.
+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.
+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!
+ + +