Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 87171 invoked from network); 8 Feb 2002 10:37:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Feb 2002 10:37:25 -0000 Received: (qmail 17420 invoked by uid 97); 8 Feb 2002 10:37:34 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 17404 invoked by uid 97); 8 Feb 2002 10:37:34 -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 17393 invoked from network); 8 Feb 2002 10:37:33 -0000 X-Authentication-Warning: bodewig.bost.de: bodewig set sender to bodewig@bost.de using -f To: ant-dev@jakarta.apache.org Subject: Re: What is going on in ANT1.x References: <20020207155832.66056.qmail@web10806.mail.yahoo.com> From: Stefan Bodewig Date: 08 Feb 2002 11:24:25 +0100 Message-ID: Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) 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 Thu, 7 Feb 2002, Jose Alberto Fernandez wrote: > The agraviating issue is that any mistake that escapes our eagle > eyes, inmediatelly becomes a feature and there is no way out of it. One of the policies I'd like to see employed is that there is absolutely no provision that we keep backwards compatibility between nightly builds, not even to beta builds or release candidates, only to released versions. I thought we had this policy, but I seem to be wrong. Maybe we'd need a longer beta cycle (and a shorter alpha cycle?) to make sure enough people have been exposed to certain features so that we may be able to remove them in time. > And I fear that we will start ANT2 with a clean slate and in less > that a year we will be back facing the same backward compatibility > isues we are facing today. This is a very valid concern - obviously it cannot be addressed completely, at least not until I can get my crystal ball to work. >> > We could define a DataTypeTaskAdaptor which takes an object, >> > defined as a datatype, and produces a Task that can be passed to >> > the TaskContainer. >> >> If an element is not known at parser time, you don't know whether >> it will be task or a data type later - how would you address this? > > By using UnknownElement. Not as a task per-se, but as a placeholder, Which kind of is what happens today - it does so by accident, but that's how it works. >> Isn't UnknownElement exactly this type of adaptor? It inherits >> from Task and manages data types at execution time as well. >> > > I really think we are overloading the meaning of UnknownElement > which produces really confusing code. I didn't mean to add something to UnknownElement, I was just stating how it is working right now. > To tell you the truth everytime I have started reading that part of > the code it take forever to understand what is going on. Same here ;-) > Also, I still do not understand why UnknownElement has to showup at > all when I use a core task like , Because ProjectHelper only looks for tasks when it processes children of TaskContainers - "path" is not recognized as a task, thus ProjectHelper assumes it must be a task that has not yet been defined. Like I said, it works by accident, not by design. > Or, we should be building a tree of only UnknownElements for > everything and then build the tree as we execute (i.e. ADOM -- Ant > DOM representation). Sure, I think this is what both Mutant and Myrmidon do - they don't call it UnknownElement (BuildElement and Configuration if I'm not mistaken), but both use proxies instead of real task instances. Doing so breaks backwards compatibility for all tasks or