Return-Path: <Jesse.Glick@netbeans.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 87681 invoked from network); 20 Jul 2000 20:08:54 -0000
Received: from lukla.sun.com (192.18.98.31)
  by locus.apache.org with SMTP; 20 Jul 2000 20:08:54 -0000
Received: from gw.netbeans.com ([129.156.76.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28041
	for <ant-dev@jakarta.apache.org>; Thu, 20 Jul 2000 14:08:52 -0600 (MDT)
Received: from appsrv.netbeans.com (appsrv.netbeans.com [212.24.138.171])
	by gw.netbeans.com (8.9.3/8.9.3) with ESMTP id WAA06373
	for <ant-dev@jakarta.apache.org>; Thu, 20 Jul 2000 22:08:49 +0200
Received: from netbeans.com (IDENT:jglick@karlovo-nb.netbeans.com
 [212.24.138.185])
	by appsrv.netbeans.com (8.9.3/8.9.3) with ESMTP id WAA08106
	for <ant-dev@jakarta.apache.org>; Thu, 20 Jul 2000 22:08:49 +0200
Sender: Jesse.Glick@netbeans.com
Message-ID: <39775C45.34301E3D@netbeans.com>
Date: Thu, 20 Jul 2000 22:08:37 +0200
From: Jesse Glick <Jesse.Glick@netbeans.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Immutable Properties in 1.1?
References: <39775617.A7E96828@seaconinc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Roger Vaughn wrote:
> I have to agree that the example given on the download page is worth
> preventing, but I have been using redefined properties for perfectly
> legitimate purposes - to simplify constructing sets of similar targets
> in my builds.

I should mention that I have done some work on an experimental patch to
the core (I know, hisses) which should permit you to specify templates
for targets rather than concrete targets. The syntax is pretty simple,
using regular expressions (not ideal but simple to understand and very
flexible):

<project name="foo" default="echo-hello" basedir=".">
  <target pattern="echo-(.*)">
    <echo message="I say: $[1]"/>
  </target>
</project>

This should print "I say: hello". In other words, the target is really a
template; it is instantiated on demand and $[number] variables in
substitutable places within the target body are replaced by the
corresponding regex match strings. If you have used Perl, sed, etc. then
the idea should be pretty clear. That example is dumb of course but more
to the point:

> <target name="jar1">
>   <property name="jarfile" value="jar1.jar"/>
>   <property name="includes" value="**/somefiles"/>
>   <!-- some code that uses ${jarfile} and ${includes} -->
> </target>
> 
> <target name="jar2">
>   <property name="jarfile" value="jar2.jar"/>
>   <property name="includes" value="**/someotherfiles"/>
>   <!-- some code that uses ${jarfile} and ${includes} -->
> </target>

This would become:

<project name="xxx" basedir="." default="all-jars">
  <target name="all-jars" depends="jar1,jar2"/>
  <target pattern="jar([0-9]+)">
    <echo message="Running target $[0]..."/>
    <someJarTask jarfileToUse="jar$[1].jar"
                 includeList="**/someotherfiles-$[1]"/>
  </target>
</project>

No property mutation or copy-and-paste required. For those familiar with
GNU make, this is similar to use of % patterns in make targets, except
more flexible (regexps vs. shell patterns, and multiple match
substrings). You can have as many templates as you need; the first one
which matches a required target name will be used.

I would appreciate any thoughts on whether people would find this sort
of thing valuable, or if there is an obvious way to get the same effect
with Ant as it is. I guess you can run an Ant sub-project but that seems
rather cumbersome. Hopefully the syntax does not appear too wretched.
One caveat: <script> will not see targets from template unless they had
been instantiated anyway; I do not see any way around this.

BTW implementation of this is a headache: can I suggest for the future
that ProjectHelper parse the document, *then* go through and construct
targets and tasks (depth-first-search from root)? That would greatly
simplify changes like this (at the expense of a small increase in memory
at runtime). It would also be helpful when running Ant embedded in some
other tool (parse one, run many). Especially since properties are set
while parsing, which seems sort of a hack.

-Jesse

-- 
Jesse Glick   <mailto:Jesse.Glick@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR