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 19084 invoked from network); 9 Dec 1999 10:53:45 -0000
Received: from pop.systemy.it (194.20.140.28)
  by 63.211.145.10 with SMTP; 9 Dec 1999 10:53:45 -0000
Received: from apache.org (pv32-pri.systemy.it [194.21.255.32]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id LAA08940 for
 <tomcat-dev@jakarta.apache.org>; Thu, 9 Dec 1999 11:53:36 +0100
Message-ID: <384EAA98.E564ED64@apache.org>
Date: Wed, 08 Dec 1999 19:59:36 +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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Costin.Manolache@eng.sun.com wrote:
> 
> > What about something like
> >
> >  <properties file="ant-${java.os}.properties"/>
> >
> > instead?
> 
> It is ok too.
> DefaultProperties is supposed to do the same thing, automatically
> ( you may have differences between Linux on Sparc and i386 ).
> Also, you may have personal settings ( .ant.properties ).

Well, I love automatic things, but not those behind my back. This
because tomorrow I know I won't remember the syntax of the file
_automatically_ called (I never do in UNIX shells) and I have to look
them up every time.

> Look at RPM - they use a similar aproach.

Yes, that's why I don't like it :)

Properties are defined in the build.xml file or in external files to
reduce verbosity and to allow property-dependent operation. I don't
think we need anything else.
 
> The ideea is not only to load some properties from a file, but to
> have a common set of definitions for all projects.
> ( including the datestamp ).

Yes, I see that.
 
> > > - add Property.java task - it will do exactly the same as the <property>
> > > hack
> >
> > You mean making <property> a task? Hmmm, it is not a task. What do you
> > accomplish?
> 
> <property> is hardcoded in ProjectHelper - it is hard to change it there.
> ( like setting only for a particular OS, or anything else).
> The problem with property is that it makes everything OS-dependent
> ( I want to put the final build into ftp public dir - that's OS dependent ).
> 
> There are similar "tasks" I'll need - like <apache-home> ( a task that
> will look for apache in well-known locations and set APACHE_HOME
> property). It would be strange to have some property setters as Tasks
> and <property> as a special case in ProjectHelper.

Makes sense.
 
> > > - Change Project.java: if a "init" target is defined, that will be
> > > executed allways
> > > before anything else.
> > > All <property/> and <defaultProperties/> defines will be here.
> > > A good ideea would be to have TaskDef in the init section too ( with a
> > > TaskDef task ).
> >
> > Let's keep things simple. Look at this pseudo-DTD
> >
> > <!ENTITY % init 'properties|property'>
> > <!ELEMENT project ((%init;)*, target+)>
> >
> > everything that is before the targets gets executed before the target.
> 
> The problem is that ProjectHelper needs to be changed to add anything
> before target.
> 
> You may have more things to do to init - besides setting properties.
> ( taskdef is one - probably in time we will discover other )
> 
> With <target name=init> it is even simpler - you no longer have property
> as a special case, everything follow the same pattern ( project=collection of
> targets,
> each target= collection of actions).

Ok, let's clear things out

<project>
 <target name="init">
  <property name="" value=""/>
  <properties file=""/>
 </target>

 <target>
  ...
 </target>
</project>

is this right?
 
> > I like this, but let's keep things simple.
> 
> That is the intention. Property in ProjectHelper is not simple.
> 
> Another aproach would be to load system properties automatically,
> without an explicit <default-properties>.

I thought system properties were already copied over to Ant? isn't it
so?

BTW, I have another thing I would like to discuss with you people. For
Cocoon, I need to be able to act differently depending on classes
present in the classpath at build time. For example, to avoid compiling
the module for Xalan integration if Xalan is not present.

This comes very handy for highly dynamically modular programs like
Cocoon but Tomcat might benefit from this very much.

I propose to do something like this

 <if class="org.apache.xalan.xslt.XSLTProcessor">
  <task .../>
 </if>

where the element "if" is not a task, but a task-flow modifier. Note
that this changes _a_lot_ Ant original architecture, because tasks
cannot nest.

I don't want Ant to become an XML-ized makefile so I won't propose stuff
like <while> <switch>, etc.. (even if some will in the future). Ant
build.xml should not became a turing language, but we need ways to
"react" on system properties like OS, file/class availability, without
having to specify a new target for every-one of these cases, or, even
worse, add a new task for anything slighly different.

Also, this paradigm shift, would allow to have stuff like

 <javadoc>
  <doclet .../>
 </javadoc>

or 
 
 <compiler ...>
  <javac .../>
  <jikes .../>
  <guavac .../>
  <pizza .../>
 </jcompiler>

following the OO-inheritance pattern.

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