Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 36374 invoked from network); 1 Nov 2001 22:13:05 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 1 Nov 2001 22:13:05 -0000 Received: (qmail 28773 invoked from network); 1 Nov 2001 22:15:24 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 1 Nov 2001 22:15:24 -0000 Received: (qmail 9734 invoked by uid 97); 1 Nov 2001 22:12:20 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 9689 invoked by uid 97); 1 Nov 2001 22:12:19 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 9642 invoked from network); 1 Nov 2001 22:12:19 -0000 Message-ID: From: Tim Dawson To: 'Ant Developers List' Subject: RE: [Ant2] Tasks as siblings of Date: Thu, 1 Nov 2001 16:12:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefan writes: > > I would prefer (1) if we made it a normal target. > > Which would be the old unmodified "no tasks outside of targets" which > received a -1 by Conor ... Well, he has to -1 it again now, doesn't he? I don't think a "-1000" counts for the next thousand times the vote is brought up. :-) Bevan Arps writes: > What about making this a proper target (ie no special syntax > or anything) > but have it identified in the project element. +1000 :-) This was actually my original request that kicked one of the earlier threads that morphed into this one. Actually, I used "init" as the attribute to keep away from the spelling (i.e. initialise vs initialize) controversies. :-) Someone had a problem with this because what if "getReady" had depends="foo". But I didn't really think that would be much of a problem. Another issue that was raised that I don't quite understand is that supposedly preprocess/validation requires top-level tasks. I mean, wouldn't it be possible to just execute the init target, and then validate all the other targets? this is effectively what happens if you have top level tasks. Tim > -----Original Message----- > From: Bevan Arps [mailto:bevan.arps@actfs.co.nz] > Sent: Wednesday, October 31, 2001 2:01 PM > To: Ant Developers List; ant-dev@jakarta.apache.org > Subject: Re: [Ant2] Tasks as siblings of > > > At 09:39 31/10/2001 +0100, Stefan Bodewig wrote: > >Seems we have three options left that didn't receive any -1s: > > > >(1) All tasks (and types) can be placed into an > construct which > >is much like a target, but cannot have dependencies of its own. All > >targets depend on this one implicitly. No tasks or types can be > >siblings of target. > > Just a thought from a satisfied Ant user ... > > What about making this a proper target (ie no special syntax > or anything) > but have it identified in the project element. > > ie something like this: > > name="myTestProject" > default="buildEverything" > initialise="getReady"> > > > ... > > > > ... > > > > > The "contract" could be simply that the initialise target always gets > executed first, reguardless of what other targets are invoked. > > I don't think that there would be any need to restrict it > from having it's > own depends list - since an initialisation target could be > used to ensure > things are available, having a number of dependencies to > check for the > availability of files/classes/xxx could be useful. > > Cheers, > Bevan. > > > > -- > "Programming is an Art Form that Fights Back" > > Bevan Arps (bevan.arps@actfs.co.nz) > Senior OO Analyst, ACT Financial Systems > > This communication is confidential to ACT Financial > Systems (Asia > Pacific) and is intended for use only by the addressee. > The views and > opinions expressed in this email are the senders own and do not > represent the views and opinions of ACT Financial > Systems (Asia > Pacific). > > -- To unsubscribe, e-mail: For additional commands, e-mail: