Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 89212 invoked from network); 30 Jul 2002 16:53:57 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Jul 2002 16:53:57 -0000 Received: (qmail 25782 invoked by uid 97); 30 Jul 2002 16:54:16 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 25733 invoked by uid 97); 30 Jul 2002 16:54:14 -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 25705 invoked by uid 98); 30 Jul 2002 16:54:13 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Tue, 30 Jul 2002 09:51:12 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Ant Developers List Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/helper ProjectHelperImpl.java In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 30 Jul 2002, Stefan Bodewig wrote: > On Wed, 24 Jul 2002, wrote: > > > But I think what we should fix is -projecthelp > > How can you fix it? You'd still need to execute if you want > to list the imported targets as well, don't you? True. I think we have requirements that can't be all satisfied, and we have to decide on what we can give up. 1. Import. In order for this to work corectly ( and -projecthelp to report all targets, including imported ones ) it clearly needs top-level tasks to be executed for projecthelp. 2. Arbitrary top-level tasks. If is used at top-level, then executing top-level on -projecthelp will lead to undesirable results. My proposal is to execute top-level before target dependency, including in the case of -projecthelp. That favors import over arbitrary top-level tasks. We can add some extra tests - for example if the has no default target or has some special attribute it'll be a target-less project and we'll not execute the top-level tasks in -projecthelp case ( and in ProjectHelper ). What do you think ? > > and make clear that whatever is at top level will be executed after > > the xml file is read, regardless of the target name to be executed. > > Not nice IMHO. If the current practice of 'property and non-action tasks' is preserved, this will work ( the same as it works in 1.5, where top-level is executed in all cases during the xml reading ). > > And we should recommend that only 'initialization' tasks > > should be at top level > > +1 - together with some examples of what we consider "'initialization' > tasks". My list would be all property setting tasks as well as > taskdef and typedef. Others? import :-) And any other 'meta-task' that affects the project structure - it can be custom task as well. ( that includes 'extend', 'include', etc ). > > - however I don't think we should enforce this too strongly, > > Can we at all? We have a range of options - from hardcoding the allowed tasks ( the current solution in 1.5 ) to marker interface to complete freedom and let the user decide. Probably the best solution would be to make a list of all options and ask for a vote - it's very much a matter of taste and I suspect no technical argument can settle this. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: