From fb9599b73c7ba11dda48e8e0e8f862500add686c Mon Sep 17 00:00:00 2001 From: Peter Donald Date: Sun, 24 Mar 2002 02:30:09 +0000 Subject: [PATCH] Zap last of frantic proposal git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@272008 13f79535-47bb-0310-9956-ffa450edef68 --- proposal/frantic/website/Task.html | 471 ---------------------------- proposal/frantic/website/index.html | 217 ------------- 2 files changed, 688 deletions(-) delete mode 100644 proposal/frantic/website/Task.html delete mode 100644 proposal/frantic/website/index.html diff --git a/proposal/frantic/website/Task.html b/proposal/frantic/website/Task.html deleted file mode 100644 index 73c808f8a..000000000 --- a/proposal/frantic/website/Task.html +++ /dev/null @@ -1,471 +0,0 @@ - - - - - - -: Interface Task - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - -
 Class  Tree  Deprecated  Index  Help 
-		 - -
- PREV CLASS  - NEXT CLASS - FRAMES   - NO FRAMES
- SUMMARY:  INNER | FIELD | CONSTR | METHOD -DETAIL:  FIELD | CONSTR | METHOD
- - -
- -

- -org.apache.ant.tasks -
-Interface Task

-
-
-
public interface Task
- -

-Task is the core interface for all structures that will be processed by the - TaskEngine. -

-

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - -
-Field Summary
-static intEXECUTION_MODE_EXPLICIT - -
-           
-static intEXECUTION_MODE_IMPLICIT - -
-           
-static intEXECUTION_MODE_PRIORITY - -
-           
-static charNAME_SEPARATOR - -
-           
-  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Method Summary
- voidexecute(org.apache.ant.engine.TaskEngine engine) - -
-          Causes the existing Task implementation to execute.
- java.lang.StringgetAttributeValue(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.
- intgetExecutionMode() - -
-          Determines whether this Task is executed whenever its parent is executed, - or if its execution must be specifically requested.
- java.lang.StringgetFullyQualifiedName() - -
-          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.
- TaskgetParent() - -
-          Returns this Task's parent Task.
- TaskgetRootTask() - -
-          Proceed backwards through the nodes until we come across the first Task - in the tree.
- TaskgetTask(java.lang.String taskPath) - -
-          A mechanism for locating a task relative to the current task.
- java.lang.StringgetTaskName() - -
-          Just a simple name used to identify a Task.
- voidinit(org.apache.ant.engine.TaskEngine engine) - -
-          Called when the Task first gets "noticed" by the TaskEngine.
- booleanisPropertyContainer() - -
-          Determines whether a Task is suitable for holding property values.
- voidsetParent(Task parent) - -
-          Sets the Task's parent.
- voidvalidate() - -
-          Each Task should have the ability to validate its state.
-  -

- - - - - - - - -
-Field Detail
- -

-EXECUTION_MODE_IMPLICIT

-
-public static final int EXECUTION_MODE_IMPLICIT
-
-
-
- -

-EXECUTION_MODE_EXPLICIT

-
-public static final int EXECUTION_MODE_EXPLICIT
-
-
-
- -

-EXECUTION_MODE_PRIORITY

-
-public static final int EXECUTION_MODE_PRIORITY
-
-
-
- -

-NAME_SEPARATOR

-
-public static final char NAME_SEPARATOR
-
-
- - - - - - - - - - - -
-Method Detail
- -

-execute

-
-public void execute(org.apache.ant.engine.TaskEngine engine)
-             throws org.apache.ant.AntException
-
-
Causes the existing Task implementation to execute.
-
- -

-init

-
-public void init(org.apache.ant.engine.TaskEngine engine)
-          throws org.apache.ant.AntException
-
-
Called when the Task first gets "noticed" by the TaskEngine.
-
- -

-validate

-
-public void validate()
-              throws org.apache.ant.AntException
-
-
Each Task should have the ability to validate its state. This would be - invoked by the TaskEngine prior to commencing an execution cycle.
-
- -

-getTaskName

-
-public java.lang.String getTaskName()
-
-
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.
-
See Also:
getFullyQualifiedName()
-
-
-
- -

-getTask

-
-public Task getTask(java.lang.String taskPath)
-
-
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. -

- Returns null of no task is found at this location.
-
- -

-getRootTask

-
-public Task getRootTask()
-
-
Proceed backwards through the nodes until we come across the first Task - in the tree. This is the root Task.
-
- -

-getFullyQualifiedName

-
-public 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. This method may be - used by the Task's hashCode() method to calculate a hash that will - uniquely identify a Task.
-
- -

-getExecutionMode

-
-public int getExecutionMode()
-
-
Determines whether this Task is executed whenever its parent is executed, - or if its execution must be specifically requested. -

-
EXECUTION_MODE_EXPLICIT
-
Requires interaction by the TaskEngine in order to execute.
-
EXECUTION_MODE_IMPLICIT
-
This Task is automatically executed when its parent is - executed.
-
EXECUTION_MODE_PRIORITY
-
These Tasks are executed prior to its parent's execution
-

- 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 not automatically fire, however all - Property Tasks do execute.
-
- -

-isPropertyContainer

-
-public boolean isPropertyContainer()
-
-
Determines whether a Task is suitable for holding property values.
-
- -

-getAttributeValue

-
-public java.lang.String getAttributeValue(java.lang.String name)
-
-
Each Task will hold its attributes in some manner. This method will allow - the Task implementation to return the value of its attribute.
-
- -

-getParent

-
-public Task getParent()
-
-
Returns this Task's parent Task. If this Task is the root Task, then this - method will return null.
-
- -

-setParent

-
-public void setParent(Task parent)
-
-
Sets the Task's parent.
-
- -

-getChildren

-
-public Task[] getChildren()
-
-
Returns the an array of Task objects that are subordinate to this Task.
- -
- - - - - - - - - - - - - - - - - -
- - - - - - - - - -
 Class  Tree  Deprecated  Index  Help 
-		 - -
- PREV CLASS  - NEXT CLASS - FRAMES   - NO FRAMES
- SUMMARY:  INNER | FIELD | CONSTR | METHOD -DETAIL:  FIELD | CONSTR | METHOD
- - -
- - - diff --git a/proposal/frantic/website/index.html b/proposal/frantic/website/index.html deleted file mode 100644 index 1491dfe4e..000000000 --- a/proposal/frantic/website/index.html +++ /dev/null @@ -1,217 +0,0 @@ - - -Ant Proposal - Frantic - - - - - -

Ant - 2.0 Proposal

-

Code Name - Frantic

-

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.

-
- - - - -
- - - - -
-

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.

-
-
-
-

 

-

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.

-

Design Proposal

-

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 Task

-

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.

-

Task Discovery

-

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.

-

Attribute Validation

-

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 Execution Engine

-

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.

-

Properties

-

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.

-

Attributes

-

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.

-

Execution Events

-

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.

-

Scripting

-

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.

-

Recursive Tasks

-

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.

-

Summary

-

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!

-

Jim Cook
- Visual XS

- -