ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Richardson <e...@milagrosoft.com>
Subject Ant 2 suggestions
Date Tue, 12 Jun 2001 16:47:55 GMT
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

Mime
View raw message