Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 87805 invoked from network); 12 Nov 2008 12:01:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Nov 2008 12:01:20 -0000 Received: (qmail 25075 invoked by uid 500); 12 Nov 2008 12:01:27 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 24724 invoked by uid 500); 12 Nov 2008 12:01:26 -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 24713 invoked by uid 99); 12 Nov 2008 12:01:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Nov 2008 04:01:26 -0800 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.146.178] (HELO wa-out-1112.google.com) (209.85.146.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Nov 2008 12:00:08 +0000 Received: by wa-out-1112.google.com with SMTP id k40so189638wah.28 for ; Wed, 12 Nov 2008 04:00:42 -0800 (PST) Received: by 10.115.92.2 with SMTP id u2mr6089942wal.228.1226491241350; Wed, 12 Nov 2008 04:00:41 -0800 (PST) Received: by 10.114.169.14 with HTTP; Wed, 12 Nov 2008 04:00:41 -0800 (PST) Message-ID: <66544f950811120400s133b714ex14c1306460d9dac6@mail.gmail.com> Date: Wed, 12 Nov 2008 13:00:41 +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_1795_23513117.1226491241315" References: <66544f950811110805s9eebef5t246f6d81b1f0add9@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_1795_23513117.1226491241315 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Thanks for the explanation, it indeed seems to be a nice feature, however my first concern would be the order of execution. I can imaging that the easiest way to implement is a first-in-first-out approach (or first-in-first-executed in this matter). If I understand correctly the target-group, or phase (would be my preference), is a very top-level element that simply specifies a grouping of tasks, it doesn't deal with the order in which tasks are performed. The required order is still defined using the depends attribute on targets. The order of registered targets will be defined by the attribute on the target-group, plus the targets that register themselves once they are loaded (load order is defined by normal processing of targets and imported build files). So, this target-group element is only useful if order doesn't matter in the phase, like in the example of having different types of tests. If order does matter, this would then needed to be solved using the depends attribute. But that also requires making sure that certain targets are not executed twice, which means one would need to add succeeded properties and have unless conditions to check them, right? Or spent time thinking about the order in which targets or build files are imported into the project and processed. Is there a way to solve the issue of ordered execution? I think that would make it even more powerful. In addition, perhaps dynamic inclusion of build files (within targets) can be a valuable extension to this phase feature. Different question, but maybe related: is there a way to specify that a build file should only be imported once (for instance, if different nested files have import statements referring to the same file)? Cheers, Remie On Wed, Nov 12, 2008 at 8:21 AM, Jeffrey E Care wrote: > > "Remie Bolte" wrote on 11/11/2008 11:05:48 AM: > > > Can you explain the concept of targets being able to add themselfs as > > dependencies? > > I can't really picture this :) > > I wasn't involved in the definition of this so don't take my word as > gospel, but this is my understanding: > > Assume you have a lot of projects & want to define a standard set of build > files (with a standard set of targets) for them all to use. You have a > "test" target for each project that can run any number of other targets to > perform specialized testing tasks: load testing, unit testing, etc. > > As things are today your standard test target needs to know about every > potential kind of testing that ANY of the projects MIGHT need to do & add > each of those other targets as a dependency. You basically then have to > define an empty implementation of each one of those specialized targets in > your standard set of build files, otherwise your test target will blow up > when building against one of your projects that doesn't implement some > particular kind of testing. > > This target-group concept turns that around; think of it as dependency > injection. It's defining a target name and saying "Hey, if you want to be > run when I run, please tell me" as opposed to the current situation of "Hey, > I know what I need to do without any help". It's a callback, an extension > point, an event listener, pick a metaphor. > ____________________________________________________________________________________________ > Jeffrey E. (Jeff) Care *carej@us.ibm.com* > IBM WebSphere Application Server WAS Release Engineering > > [image: WebSphere Mosiac] [image: WebSphere Brandmark] > > ------=_Part_1795_23513117.1226491241315--