ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Richardson <>
Subject Re: Ant 2 suggestions
Date Wed, 13 Jun 2001 15:05:53 GMT
Peter Donald wrote:
> Interesting. You are the second person to describe this but I think I like
> your explanation better ;) (Made more sense to me).

Thanks, I appreciate that.

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

I took a look at the ant 2 features document
( and the
requested-features.html and my proposed approach makes alot of sense.
Everything could be super-simplified and the DTD or schema would be
pretty much trivial. I also recognized that if a task was defined in a
process methodology way, they could be used internally to ant as well.
Much of what ant is trying to do has been done in make and sh. This
approach could provide a unification and a clean syntax. I studied
process methodology, scheduling and simulation in school so I spent alot
of time looking at exactly these types of problems. I realize this is
probably much too radical but ant is way more complicated than it needs
to be. Having different tag names for every task is not necessary.

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

View raw message