From dev-return-83669-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Fri Nov 14 10:09:52 2008 Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 72871 invoked from network); 14 Nov 2008 10:09:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Nov 2008 10:09:50 -0000 Received: (qmail 28356 invoked by uid 500); 14 Nov 2008 10:09:56 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 28309 invoked by uid 500); 14 Nov 2008 10:09:56 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 28298 invoked by uid 99); 14 Nov 2008 10:09:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Nov 2008 02:09:56 -0800 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Nov 2008 10:08:36 +0000 Received: by ug-out-1314.google.com with SMTP id x30so1609066ugc.16 for ; Fri, 14 Nov 2008 02:09:16 -0800 (PST) Received: by 10.103.49.12 with SMTP id b12mr250303muk.81.1226657355939; Fri, 14 Nov 2008 02:09:15 -0800 (PST) Received: by 10.103.92.15 with HTTP; Fri, 14 Nov 2008 02:09:15 -0800 (PST) Message-ID: <66544f950811140209v3d4ad573s73f735025a91ca7d@mail.gmail.com> Date: Fri, 14 Nov 2008 11:09:15 +0100 From: "Remie Bolte" To: "Ant Developers List" Subject: Re: EasyAnt phases In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3484_23328488.1226657355965" References: <66544f950811110805s9eebef5t246f6d81b1f0add9@mail.gmail.com> <66544f950811120400s133b714ex14c1306460d9dac6@mail.gmail.com> <491C7B41.6050406@callenish.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_3484_23328488.1226657355965 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Perhaps it is possible to create a dependency between phases, and additionally give targets the possibility to depend on a phase i.e.: (please don't mind the names, i'm not following this topic close enough to know them or make suggestions, it's just an example). This way it is possible for a target to rely on having a certain build phases executed. Personally, I don't see a good way of implementing ordering in phases, wheter or not this is desired. However, I think the concept of ordering and the community dependency on this behavior should be taken into this discussion. That was the only point I tried to make :) BTW: there are situation in our product builds where we specify the dependencies the way described by Dominique, using the antContrib runtarget task. I can image that having a dependency task that can be placed at any point inside a target allows more flexibility. Cheers, Remie p.s. Thanks again for taking the time to explain certain behavior and past considerations. Some of my comments and suggestions might feel redundant for those might have already been discussed in the past. On Fri, Nov 14, 2008 at 6:02 AM, Stefan Bodewig wrote: > On 2008-11-13, Bruce Atherton wrote: > > > Conceptually I agree with you, but I think we need to recognize why > > people would want this and to validate their concerns. > > I wasn't advocating we change the current behavior, Ant's own build > file relies on it in much the same way as > > > Consider these targets: > > > ... > > ... > > for example see the way we structure our test targets. > > depends="dump-info,junit-tests,antunit-tests,check-failed" > > and "check-failed" doesn't depend on anything, so with a different > executor model it might be run before any test has started. > > In the context of phases I think we don't need control over ordering > since the targets that want to add themselves to phases shouldn't > really depend on each other. If they do - that's what I meant to say > - then it smells as if an additional intermediate phase was missing. > > But your example got me thinking. It is pretty easy to imagine that > there would be "build" and "clean-build" phases much like what you > have shown with target. If my target wants to do something only in > the clean-build phase it will most likely make a difference whether it > is run before or after "clean". > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org > For additional commands, e-mail: dev-help@ant.apache.org > > ------=_Part_3484_23328488.1226657355965--