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 50344 invoked from network); 11 Dec 1999 14:22:33 -0000
Received: from pop.systemy.it (194.20.140.28)
  by 63.211.145.10 with SMTP; 11 Dec 1999 14:22:33 -0000
Received: from apache.org (pv9-pri.systemy.it [194.21.255.9]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id PAA23114 for
 <tomcat-dev@jakarta.apache.org>; Sat, 11 Dec 1999 15:22:15 +0100
Message-ID: <38524F37.FBD06185@apache.org>
Date: Sat, 11 Dec 1999 14:18:47 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,it
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: Ant
References: <384C1116.6D1DB7C1@eng.sun.com> <384D549F.289A4E92@apache.org>
 <384DFFD7.13ED6515@eng.sun.com> <384EAA98.E564ED64@apache.org>
 <384FD993.E8BEA86E@eng.sun.com> <3850E9D8.F724C36E@apache.org>
 <38515063.672436E9@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

costin@eng.sun.com wrote:
> 
> > Isn't this getting too much "tomcat-driven"? I totally understand your
> > problems and your solutions and I think they could be great for a tomcat
> > builder, but I'm afraid of doing too many things behind my back.
> 
> Creating a distribution archive and puting it in a ftp directory is not
> tomcat specific. Neither using TSTAMP in the name.

Agreed. I was only afraid of stuff like <apache-home> that get much
dependent on what you're doing (see the "taglib" stuff below).
 
> IMHO if a project needs a special Task and it feels like generic
> enough - we should just add it.
> ( like compiling a package only if a class is in classpath - I think
> it's something usefull ).

Totally. We should be just careful and do it generic enough, this is my
only concern.

> > Something like
> >
> > <propfile name="xxx.properties"/>
> > <propfile name="xxx-${java.os}-${java.arch}.properties"/>
> > <propfile name="~/.xxx.properties"/>
> 
> Agreed.

Cool.
 
> > Hmmm, I wonder... we have tasks and we have properties, what we miss is
> > a task that generates a property. Something like
> >
> >  <property name="stamp" type="timestamp" .../>
> 
> What about a task that sets the property ?

Yes, this is what I was proposing.

> I use <dstamp> task, and I plan to add tasks that will look for Apache
> and other packaged. ( looking if a class is defined and setting a property
> if so might also be usefull).
> 
> No need to invent a new mechanism for that.

Exactly. All of your <apache-home> <ftp-dir> <tstamp> etc... happen to
fall in the "namespace" of elements that set a property based on some
logic. This is what JSP called a "taglib" (in XML you'd call it a
"namespace" but either is fine as far as we understand each other).

So, I totally agree we need better hooks for properties that "static,
passed at command line, or found in a bunch of files if present".

We need a PropertyTask with execute() that returns a String and 

 <property name="apache.dir" generator="ApacheDir" dir="home"/>

where

public ApacheDir extends PropertyTask {

   private String dir = null;

   void String execute() throws BuildException {
      if (dir.equals("home")) {
        // look in the system for apache
        // return the generated string
      }
   }

   public void setDir(String s) {
     this.dir = s;
   }
}

is a subtask of the Property task.

what do you think?

> > Again, I'm _very_ afraid of going in this direction since we loose focus
> > on portability. If we had namespace support we could add a sort of
> > "taglib", but you don't want to get that complex at this point.
> 
> Ok, I guess I was wrong in the first attempt.
> 
> Proposal:
> 
> - add <target name="init"> and put all initial properties and taskdefs
> there.  The code will maintain backward compatiblity, but on long term
> it would be nice to migrate the antfiles to this model.

I volunteer to update all the ant build file in xml.apache.org, we shoud
impose changes this drastic at this point rather than in the future
where more and more people will use Ant.

+1 on back incompatibility and allow only targets to reside at the
second level.

 <project>
  <target>
   <task/>
  </target>
 </project>

that's it.
 
> - Property.java implements Task will be used instead of a special
> code in ProjectHelper. Simpler is better :-)

+1 
 
> - <Properties file="name-${os}"> will be used to eliminate
> any OS-dependent property.

+1 

This said, we still miss the feature of executing a target reacting on
the system status (i.e. non executing a target if the required class is
not found in the classpath)

I propose the following (that matches with current Ant XML limitations
and keeps things simple from a scripting complexity of the DTD)

 - <target name="" depends="" condition=""/>

where condition is a boolean condition that allow the target to be
executed if the attribute is considered true and it defaults to true.
So, for example,

 <project>
  <target name="init">
   <property name="xalan" generator="classpath"
class="org.apache.xalan.xslt.Process"/>
  </target>
  <target name="xalan" condition="${xalan}">
   <!-- compile Xalan support -->
  </target>
 </project>

What do you think?

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