Return-Path: 
 <user-return-71789-apmail-ant-user-archive=ant.apache.org@ant.apache.org>
X-Original-To: apmail-ant-user-archive@www.apache.org
Delivered-To: apmail-ant-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 89BC164D5
	for <apmail-ant-user-archive@www.apache.org>;
 Fri,  8 Jul 2011 15:53:23 +0000 (UTC)
Received: (qmail 47831 invoked by uid 500); 8 Jul 2011 15:53:22 -0000
Delivered-To: apmail-ant-user-archive@ant.apache.org
Received: (qmail 47692 invoked by uid 500); 8 Jul 2011 15:53:22 -0000
Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:user-unsubscribe@ant.apache.org>
List-Help: <mailto:user-help@ant.apache.org>
List-Post: <mailto:user@ant.apache.org>
List-Id: "Ant Users List" <user.ant.apache.org>
Reply-To: "Ant Users List" <user@ant.apache.org>
Delivered-To: mailing list user@ant.apache.org
Received: (qmail 47684 invoked by uid 99); 8 Jul 2011 15:53:21 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 15:53:21 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 209.85.218.45 as permitted sender)
Received: from [209.85.218.45] (HELO mail-yi0-f45.google.com) (209.85.218.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 15:53:14 +0000
Received: by yia25 with SMTP id 25so997933yia.4
        for <user@ant.apache.org>; Fri, 08 Jul 2011 08:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type:content-transfer-encoding;
        bh=vDn8DuaF7KWL/ilpFclkTPCM/pdLvuriu3iB2ZHqRzA=;
        b=cl8nhT4DuCSKU2rJySRcnHBEOH5/3OD2JYqtoYLTffj2tNtHPBE3v3J0W5LV/FFBPj
         vnLFeqNplb7dRexHLWwGaHr3XGCZmJ79yhOfCPk9jZ79aTYuiotFHl0oC+4BE1bXiuiM
         oSwIy3dUuj0sSLUVS6iJ75fFfTPCaTMOaCBjo=
MIME-Version: 1.0
Received: by 10.236.79.132 with SMTP id i4mr2266074yhe.288.1310140374198; Fri,
 08 Jul 2011 08:52:54 -0700 (PDT)
Received: by 10.147.83.9 with HTTP; Fri, 8 Jul 2011 08:52:54 -0700 (PDT)
Reply-To: gudnabrsam@gmail.com
In-Reply-To: 
 <CAFCRh-8Aqm7xt_P6NOqOZ+4Nom9fyGcfPtJbLur-d=x_561R1Q@mail.gmail.com>
References: <4E17204F.6090900@sas.com>
	<330B5A2BAB417E47A0BBB442C7BCB99D02B4CF1C@HQ-MAIL8.ptcnet.ptc.com>
	<CAFCRh-8Aqm7xt_P6NOqOZ+4Nom9fyGcfPtJbLur-d=x_561R1Q@mail.gmail.com>
Date: Fri, 8 Jul 2011 10:52:54 -0500
Message-ID: 
 <CAE9L6G1h7pnonNFvqz0ANJZaap=Ns7YpdyaqyyE_a_M3qKaFuA@mail.gmail.com>
Subject: Re: Equivalent: <ant
From: Matt Benson <gudnabrsam@gmail.com>
To: Ant Users List <user@ant.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

On Fri, Jul 8, 2011 at 10:49 AM, Dominique Devienne <ddevienne@gmail.com> w=
rote:
> On Fri, Jul 8, 2011 at 10:27 AM, Perrier, Nathan <nperrier@ptc.com> wrote=
:
>> No, because antcall creates a new project underneath the hood, whereas r=
untarget (antcontrib task) does not.
>
> I would add that <runtarget> (and <antcall> as well in fact) goes
> against the Ant philosophy of having declarative builds using targets
> with proper dependencies between them, where by "dependencies" I mean
> that target just state their "requirements" and should not care when
> or in which order those requirements are fulfilled, =A0since that's the
> job of the "dependency manager" to analyze the graph of targets and
> order them such that each one runs only once and in the proper order,
> detecting circular references. Targets are not functions that one
> would call at will, leading to procedural as opposed to declarative
> builds. <macrodef> usage should eliminate the need for most
> <runtarget> usage and is preferred in general.
>
> In more practical terms, <antcall> does indeed create a new project
> (i.e. a new "scope"), which means that any property it sets will not
> be visible to the build that used <antcall>. <runtarget> does not
> create a new Project, so all properties set *are* visible to the
> "caller", and it achieves that via a loophole in Ant's API which is
> not plugged for backward-compatibility reasons.
>
> Using <antcall> and <runtarget> is IMHO a symptom of using Ant and
> builds with a wrong (procedural) mindset. I've created lots of large
> and complex builds in the past without any, so it's certainly not
> necessary to idiomatic Ant usage, although it remains quite popular to
> many :) My $0.02. --DD

And since Ant 1.6 I have never found a problem that would formerly
have been solved by e.g. <antcall> that couldn't be solved with
<macrodef>, and so reducing dependencies on external libraries while
still avoiding the overhead of the additional project instance.

Matt

>
>> -----Original Message-----
>> From: Steve Amerige [mailto:Steve.Amerige@sas.com]
>>
>> Are the two statements below equivalent?
>> <antcall target=3D"doit" InheritRefs=3D"true" />
>> <runtarget target=3D"doit" />
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org