Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Content-Type: text/plain;
  charset="iso-8859-1"
From: Peter Donald <donaldp@apache.org>
To: ant-dev@jakarta.apache.org
Subject: Re: Question about properties and ant2
Date: Wed, 12 Sep 2001 12:13:28 +1000
References: <200109110509.BAA05716@java.odi.com>
 <20010911071654.HGDY4715.mss.rdc2.nsw.optushome.com.au@there>
 <200109111934.PAA07666@java.odi.com>
In-Reply-To: <200109111934.PAA07666@java.odi.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20010912023752.HCXT4715.mss.rdc2.nsw.optushome.com.au@there>

On Wed, 12 Sep 2001 05:34, Claudio Corsi wrote:
> > From: Peter Donald <donaldp@apache.org>
> >
> > sorta. Theres two issues in that. Are properties immutable (ie unable to
> > be changed) ? and will "configuration" of tasks pick this up? The first
> > issue (ie making properties mutable rather than immutable) had no clear
> > consensus IIRC. The second issue is mostly true of current ant *except*
> > in certain rare occurences (when the same task is executing multiple
> > times - like from a script but property values have changed). We will
> > just fix this minor and rare case and thus allow easier manipulation of
> > ant systems from your favourite scripting language
> > (javascript/python/whatever).
>
> This said, then how would I go about including a variable within the xml
> file that is immutable and can be used throughout the xml file? If this
> does not exist, can something like this be implemented? This can be for
> ant1 or ant2.

I think you mean mutable (ie changeable) not immutable. The only real way to 
do this today is via antcall and setting parameters in the antcall. Antcall 
actually creates a new Project instance and optionally populates it with 
property values again.

> The reason is that I have a project that includes multiple targets that
> perform the same tasks but that certain variables are different for each
> task. I thought of creating a single target that is called by the other
> targets. This target uses properties to determine how to run the given
> target.

This is what has been termed templating and ant1.x really doesn't support 
this well at all. Depending on your specific requirements antcall may work 
for you.

> The reason behind the implementation of these targets is that our xml file
> is starting to become large. I started to refractor the xml file to make it
> simpler to add new targets without adding too much to the xml file. This is
> where this idea came from and I really believe that this concept should be
> added if not already their.

Support for these functions will be added in time (I have been calling for it 
for about a year now) but it is unlikely to happen before Ant2.

-- 
Cheers,

Pete

----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------