Interesting. You are the second person to describe this but I think I like
your explanation better ;) (Made more sense to me).
When we talked about this last time we talked about a "File Aspect" that
was applied to tasks. Ant2 will support this approach but will require some
support from task writers. It would be interesting to try but I don't think
there is any plans to do that at the moment.
At 09:47 AM 6/12/01 -0700, Eric Richardson wrote:
>Hi,
>I've been an Ant user since the early days but had not followed
>developments too closely from the early versions as they did the basics
>I needed. As some background on me, I have had to create build
>procedures and CM procedures at each place that I have worked and I was
>really pleased with Ant as a Java build tool and implemented it at a
>company a couple of years back.
>
>Recently, I downloaded the 1.3 version. The documentation is fair but as
>I'm working on documentation on another open source project I'm
>appreciative to have some. Thanks to those people. Otherwise, I was
>pretty disappointed not that the new things aren't cool but it is very
>difficult to decide how to use the different filesets etc.
>
>In order to provide some point of reference for improvement suggestions
>I would like to start at a very high level and discuss one of the cool
>models in the software world - UNIX. One of the powerful features in
>UNIX is that a process has stdin, stdout and stderr. The 'everything is
>a file' or a device or however you would like to look at this allows
>this model to work very well. Input/Process/Output is the essence of the
>process model. Stderr could be considered to be a feedback loop from the
>process. How is this model powerful other than it models the real world
>quite nicely? It allows processes to be linked together in a chain. In
>the shell, programs that were never designed to work together can inter
>operate in a process chain (ps -ef | grep foo or cat file | wc -l
>...). The original authors or these programs could not envision how they
>might be used. The shell here does the work to pipe the output of one
>process to the input of the other. The shell also does nice things like
>wildcard expansion so you can do the following: vi *.java Anyway, these
>processes with the input/output model and the shell are very powerful.
>One other thing is that all the user commands pretty much will take
>input as a stream or a file.
>
>In Ant or any other build tool the concept is the same but the syntax
>and the approach are different. Even though make has it's problems it
>does show us the model above although it adds dependencies and
>backwards-chaining. A typical suffix rule is as follows:
>
>input-pattern output-pattern : dependencies
> process
>
>The colon is the token for depends. Some nice things are that you can
>run targets just based on the suffix rule.
>
>.c.o :
> cc ...
>
>make foo.o
> will compile foo.c if it is out of date if that macro is being run.
>
>The syntax is a nightmare but it has allot of good features and is
>useful. But the point here is the system fits the basic process model.
>
>How can this benefit Ant? First, I think Ant needs to go to a more
>formal model. In the manufacturing world the Process model is quite
>developed and even automated as in CIM (Computer integrated
>Manufacturing). What are dependencies? Dependencies are really the links
>between the processes that state an implied precondition to the next
>process. I think generally that since Ant is using a explicit markup
>language XML that being explicit is a good thing. So where are we at
>this point? First, from an exterior perspective, Ant has a project at
>the top level with targets and then tasks. Target is essentially process
>and supports basic preconditions with inclusion (if) and exclusion
>(unless). Inside a target are tasks which are really mini processes. I
>think I'm finally ready to get at the proposal.
>
>Ant's major task is to execute the linked map of targets based on the
>target name without suffix type matching and without looping based on
>the foreach thread discussion. The system handles all the basic services
>and the execution plan based on the XML build file and the requested or
>default target. I'm going to suggest a possible build file syntax for
>discussion purposes. A target is really a process that represents an
>entry point into the process map.
>
><?xml version="1.0" encoding="utf-8"?>
><!DOCTYPE project SYSTEM "project.dtd">
>
><project name="Ant2" default="all" basedir=".">
>
> <process name="all" depends="process1">
> <input>
> </input>
> <task name="java">
> <!-- builtin -->
> </task>
> <output>
> </output>
> </process>
>
> <process name="process1" depends="process0" target="false">
> <!-- target not visible to outside user -->
> <input>
> </input>
> <task name="ejb" classname="my.ejb.Packager">
> <!-- not builtin -->
> </task>
> <!-- task 2 -->
> <output>
> </output>
> </process>
>
></project>
>
>Anyway this is the basic idea from a build file perspective. If tasks
>were named as above then it is really obvious yet a bit more verbose
>than the tag name being the process. Each task would have possible input
>and output which could be filesets or other filename expansions or
>whatever makes sense. Ant could possibly have explicit dependencies that
>could be executed dependent on more complex criteria rather than the
>current "if, unless" if this feature is needed. This would require the
><depends> tag to link the two processes.
>
>The <input> and <output> tags could support filesets, suffix rules with
>perhaps nameless targets. The Ant system could call the task over and
>over with the internal foreach if the <fileset> or other input tag
>returns more than one file. The output of one process could be a stream
>and become the input to the next. Essentially Ant becomes a shell for
>tasks and processes and executes the Map of interrelated processes or
>targets.
>
>Since processes are recursive, I'm not sure if a task is really a
>process with it's own input and output. Since tasks now handle their own
>input and output for the most part it's unclear whether you can have
>multiple tasks in a process. In process lingo a process can have steps
>which in the example above is the task. Typically the steps themselves
>don't have there own Bill of Material. (eg. Input). Processes could
>optionally support the checking of time stamps for the input and output
>files if desired - of course the input and output would have to be
>files.
>
>I think that is is really easy for the person looking at the file to see
>what is going on. The internal API for building a task could use
>standard services for input and output making the task makers happy.
>This is based also on sound theory and most people are very familiar
>with the model. A recipe is a good example.
>
>Anyway I hope this can be of use.
>
>Eric
>
>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
