Return-Path: <rvaughn@seaconinc.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 90005 invoked from network); 25 Jul 2000 15:12:37 -0000
Received: from tamqfl1-60-250.biz.dsl.gtei.net (HELO charon.seaconinc.com)
 (209.241.60.250)
  by locus.apache.org with SMTP; 25 Jul 2000 15:12:37 -0000
Received: (qmail 22215 invoked by uid 0); 25 Jul 2000 14:13:47 -0000
Received: from unknown (HELO seaconinc.com) (209.118.110.30)
  by tamqfl1-60-250.biz.dsl.gtei.net with SMTP; 25 Jul 2000 14:13:47 -0000
Message-ID: <397DAE48.E669994F@seaconinc.com>
Date: Tue, 25 Jul 2000 11:12:09 -0400
From: Roger Vaughn <rvaughn@seaconinc.com>
Organization: Seascape Consulting
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Use cases pleas (was Re: Why Properties became immutable)
References: <B5A1F978.7A77%duncan@x180.com> <397CE64F.23DE1F7D@seaconinc.com>
		<3.0.5.32.20000725122520.008c1b80@latcs2.cs.latrobe.edu.au>
		<397D9869.F1B5CC2D@seaconinc.com> <m3aef6p9gl.fsf_-_@sbodewig.bost.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Stefan Bodewig wrote:

> Could you please share what kind of constructs these are. I seem to be
> too far away from *real world examples* to see all of them. If we all
> know what kind of problems to tackle we might come up with the
> simplest possible solution together.
>
> If it only was to avoid repeating targets that only differ in the
> value of some properties, sub builds seem a lot clearer to me than
> anything else I've seen proposed, including template targets and XSLT
> like constructs.
>
> Sub builds using the same build file generate an overhead that we can
> remove if we switch too runtime evaluation, but I'm actually talking
> about syntax here.
>
> <target name="templated">
>   <task using ${foo} >
> </target>
>
> <target>
>   <calltarget target="templated">
>     <param name="foo" value="..." />
>   </calltarget>
> </target>
>
> is procedural in a sense. Replace "calltarget" with "ant" and "param"
> with "property" and we are already there. I'm willing to accept that
> much.
>
> I'm still not convinced we actually need more, that's why I ask for
> use cases.
>
> Stefan

You're on.  Please don't take offense at the "real world examples" comment
- I just don't like getting barraged by comments of "it isn't needed."
This is why open source works - many different people run into many
different situations, all of which deserve respect.

The one case I currently have is that of repeated targets, as you
mentioned.  One of my projects builds 19 different jars the exact same way
- but each with a different name and selection of contents.  (I have no
control over the breakdown of the outputs, only the build procedure
itself.)  The repeated code currently looks like this:

<target name=...>
  <property ..../>
  <mkdir .../>
  <jar .../>
  <cab .../>
</target>

It isn't complex, but the repeated sections do change occasionally.  I
keep fighting like hell to get rid of those cabs....  Still, today, I have
to write this code 19 times, once for each of the jars.  What I did
originally was set the properties "target.name" and "includes" in each
target, and then used them in the following tasks, effectively
parameterizing the shared code.  This got me at least the ability to do
cut-and-paste reuse.  By your comments, this worked by accident, and broke
in 1.1 when properties became immutable.  Mutability or "target vars"
would give me at least what I had yesterday.

IMO, a more effective solution would be similar to what you have proposed
above, where the common tasks could actually be abstracted out.  I agree
with the syntax you propose, but I might perhaps create a "pattern" object
instead of a "target" just so the two could not be confused.  I understand
your comments about sub-builds being a clean way to accomplish this, but I
don't like that particular solution simply because I have seen it cause
plenty of confusion in make programmers.  (Which nesting am I on?  When
did these properties get set this way?  Why can't I just set a
dependency?)  I've done my share of 'em, too.  Under hazard of shooting
myself in the foot, it's a usage pattern rather than a declarative
construct, which makes it harder to learn and read.

I had many cases in the past where make gave me fits, but since I haven't
[yet ;-)] run into them using Ant, they aren't worth mentioning here.

What you proposed above would help.  I need no more today for all of the
noise I have made recently.

Thanks for listening,

roger