Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 61856 invoked from network); 1 Mar 2005 11:56:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 1 Mar 2005 11:56:08 -0000 Received: (qmail 30549 invoked by uid 500); 1 Mar 2005 11:56:05 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 30514 invoked by uid 500); 1 Mar 2005 11:56:04 -0000 Mailing-List: contact dev-help@ant.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 dev@ant.apache.org Received: (qmail 57631 invoked by uid 99); 1 Mar 2005 10:57:32 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Message-ID: <42244AEC.4050908@ruminate.co.uk> Date: Tue, 01 Mar 2005 11:58:52 +0100 From: James Fuller Reply-To: jim.fuller@ruminate.co.uk Organization: Webcomposite User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: a few questions (sorry quite long) References: <200502241249.j1OCnEx30518@server1.ruminate.co.uk> <421DF8D7.5020207@apache.org> <421F1B77.704@ruminate.co.uk> <42233503.2090306@apache.org> <42234D61.8090602@ruminate.co.uk> <422444D9.7050808@apache.org> In-Reply-To: <422444D9.7050808@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Steve Loughran wrote: > James Fuller wrote: > >> btw I have a few general developer questions... before I start caning >> bugzilla I think any responses would be well appreciated; > really appreciate the time you have taken to answer.....even where you have confirmed simply lets me know if something is considered optional, must do, or a bit of cruft in the source. > This makes some sense, apart from the schema bit at the bottom. > Schema? We dont need no schema :) schema can be an opt in, admittedly writing a schema would give hints to editors out there...by using NRL (namespace routing language) we can allow authors to use whatever schema lang they prefer (my own choice is RELAXNG). Also through namespace declaration we can let authors use whatever markup they choose for descriptive blocks (xhtml, etc). > Actually I like the suggestion to an extent - code is often the wrong > place to put metadata. But as most of the attributes of a task can be > determined through introspection, i think xdoclet does have something > to say. > One thing we need to be able to describe is the situation when one of > a set of attributes is needed. required being true/false is not enough. ...I think presenting a commenting style guide + task markup is something useful...will work on something in the short term. >> - getlibraries has no task definition that I can see....correct me if >> I am wrong > > > yes, was looking for manual description of the task. >> - is there a list of @ant.task category types anywhere ? > > nope usage optional then >> >> - is abstractaccess optional task @ant.task category the right way to >> use this doc tag? also any list of ant.task category anywhere ? > > nope. remember the @ant tasks were a quick draft in 2002; we dont need > to stick to them. usage optional, thx for clearing up >> >> - couldnt find any logging/listener tests under testcases ? > sacre! >> - MagicNames.java...whats the status and intended purpose ? > > Looks like it is intended to be a central repository of magic properties. from this answer I will assume its status is open, and its use optional >> - any update on webdav task > > We arent doing one. ok, this looks like a nice first submission for me then. > We cant move things. If you move stuff, you have to leave a facade > class there. Why? Because we dont know who has subclassed or reused a > class. A lot of people use ant programatically as well as in the XML > layer, and we need to keep the effective API as stable as the XML > language. This is precisely why we are org.apache.tools.Ant agree, but there are a few techniques instead of just putting facade classes...I agree with the statement you make later about backwards compatibility... > Launcher is special; it is its own JAR file, and has to locate and > launch ant proper. it must be 100% self-contained. ok, thought this was the case. >> Why not move ? >> -main/org/apache/tools/bzip >> -main/org/apache/tools/bzip2 >> -main/org/apache/tools/mail >> -main/org/apache/tools/tar >> -main/org/apache/tools/zip >> excuse my ignorance here (well if u never ask questions...)....are >> these are org.apache.tools packages used by other apache projects > > > I think they did come from other projects, and are designed for reuse > outside ant. was wondering if there is a more appropriate apache project for these org.apache.tools.* packages.... >> - why are these tests at toplevel ? >> testcases/org/apache/tools/mail >> testcases/org/apache/tools/tar >> testcases/org/apache/tools/zip > > > maybe because the things they test are at that level. hehe, this is linked to why we have such top level packages...once again history. > > yes, there is lot of historical stuff. Eventually we will be crushed > by the weight of backwards compatiblity. > > I have just updated the ant_task_guidelines doc in the repository, > please take a look at this and see if it clarifies things. thx for taking the time to answer such tiresome questions.... cheers, Jim Fuller --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org