Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 41246 invoked from network); 30 Nov 2001 17:03:01 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Nov 2001 17:03:01 -0000 Received: (qmail 99 invoked by uid 97); 30 Nov 2001 17:01:25 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 29928 invoked by uid 97); 30 Nov 2001 17:01:16 -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 29684 invoked from network); 30 Nov 2001 17:01:06 -0000 Message-Id: <200111301701.fAUH14u15300@mail012.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Ant Developers List" Subject: Re: Ant1.9 Refactoring? Date: Sat, 1 Dec 2001 03:10:43 +1100 X-Mailer: KMail [version 1.3.1] References: <200111281035.fASAZxO18364@mail016.syd.optusnet.com.au> <003201c17916$97b75360$0201a8c0@nordwand> In-Reply-To: <003201c17916$97b75360$0201a8c0@nordwand> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Fri, 30 Nov 2001 07:43, Steve Loughran wrote: > I am +1 for refactoring, but think that some of it could be done in a way > which feeds back into the main branch early on. The problem is not the build.xml format because we could easily refactor if that was the only "consumer" of ant. However as it stands our contract is at the java level because tasks quite commonly create other tasks and manipulate them directly ;( > > * creation of infrastructure to support *coloring* and other > > +1. Does conor's datatype patch make this possible today? not sure how Conors datatype patch relates to coloring. Coloring is detecting when things like "debug" attributes are changed in javac and forcing all .java files to be recompiled. > my interests: > dynamic loading of task libraries from a descriptor I can't see this changing too much in ant1 - sorry ;( > use of xdoclet and marked up tasks to generate deployment descriptors, docs > automatically +1000 > > (1) the container (think the servlet engine + servlet API) > > (2) the framework (think turbine or struts or another web framework) > > (3) the tasks > > > > (2) is probably one of the most important bits in that it determines what > > the > > > tasks look like. It defines the notion of fileset and so forth. > > One of the most similar 'frameworks' is the whole taglib model itself. What > is good and bad about that that we can apply (or omit) from the anttag > model? I would correlate the taglib model with the (3) and I think I actually refer to them as s. If we have a rul that no tasklib can rely on another tasklib and shared functionality is factored out into a framework layer then I think it works well. Then again I haven't seen the negatives of taglib model - what are they ? > Branches can take a life of their own if we arent careful, and this is > going to complicate the world. It will effectively mean a stabilising of > the main trunk while people focus their effort off to the side. Which is > not necessarily a bad thing. +1 -- Cheers, Pete *------------------------------------------------------* | Despite your efforts to be a romantic hero, you will | | gradually evolve into a postmodern plot device. | *------------------------------------------------------* -- To unsubscribe, e-mail: For additional commands, e-mail: