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!
- - -