From stefano@apache.org  Fri Nov 26 17:57:11 1999
Return-Path: <stefano@apache.org>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 19525 invoked from network); 26 Nov 1999 17:57:11 -0000
Received: from pop.systemy.it (194.20.140.28)
  by apache.org with SMTP; 26 Nov 1999 17:57:11 -0000
Received: from apache.org (pv45-pri.systemy.it [194.21.255.45]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id SAA22889 for <tomcat-dev@jakarta.apache.org>; Fri, 26 Nov 1999 18:57:06 +0100
Message-ID: <383EB053.30EB1298@apache.org>
Date: Fri, 26 Nov 1999 17:07:47 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: it,en
MIME-Version: 1.0
To: Tomcat <tomcat-dev@jakarta.apache.org>
Subject: Still playing around with Ant
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi guys,

other random comments on top of my head (sorry, but I don't have time to
implement them)

1) the Task interface should have methods that return basic information
on what the task does. Something like apache modules that expose their
behavior as well as their configurations.

Something like

public class Echo implements Task {
  String getHelp() {
    return "ouputs the given string to STDOUT";
  }
}

so that you can do 

  ant --help

and you get a list of supported tasks. Then

  ant --help echo

and you get the help for the echo task, right there.

You could do this also for attributes

  String getxxxHelp()

(if present) returns a help message for the "xxx" attribute, as well as

  String getxxxDefault() 

(if present) returns the default value for the "xxx" attribute.






2) Taks is an abstract class. Following the "polymorphic" design
pattern, we should have

 public interface Task

which includes the method definitions only, then

 public abstract class AbstractTask

which includes the methods shared between all tasks, then
 
 public abstract class FileTask

which includes all the common utility methods for file tasks (like are
today contained into Task.java), and you can have a bunch of abstract
classes for common tasks, that may be abstract or not, depending if they
are usable or not

 public class Exec extends AbstractTask

and

 public class Cvs extends Exec

while

 public class Copydir extends FileTask





3) Task.java should contain a method 

 setLog(PrintWriter log, boolean useXML)

to indicate where the class should place logs and if the XML syntax
should be used. The task should be guaranteed this method is _always_
called before any execution.



4) I don't like Jon's <keysubst> usage. I do consider it vital to have a
task that performs token substitutions, but I'd like to propose
something a little different. Consider something like this

<keysubst src="try.java" dest="try.new.java" 
   setKeys="version=$(version)*name=$(name)*debug=$(debug)"/>

it performs both a copy and a substitution, which is IMO no good.

I would like to be able to do

 <copydir src="src" dest="$(build.src)"/>
 <replace file="$(build.src)/Main.java" token="@version@"
value="$(version)"/>
 <replace file="$(build.src)/Main.java" token="@name@" value="$(name)"/>
 <replace file="$(build.src)/Main.java" token="@debug@"
value="$(debug)"/>
 <javac srcdir="${build.src}" destdir="${build.dest}" debug="${debug}"/>

and doing this with keysubst is much more verbose globally, even if it
encodes all the keys into one line.

The behavior is different, this is true, and much slower, granted, but
I'd like to have a task for copying the files and another for updating
them. keysubst is modeled out of the "sed" pattern, which is really
powerful, but IMO a pain in the ass to read (and to manage!) and works
well in pipes, that we don't have here.

Comments?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche