Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 97977 invoked from network); 4 Dec 2002 21:48:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Dec 2002 21:48:38 -0000 Received: (qmail 18131 invoked by uid 97); 4 Dec 2002 21:49:45 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 18093 invoked by uid 97); 4 Dec 2002 21:49:44 -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 18074 invoked by uid 98); 4 Dec 2002 21:49:43 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Sent: 4 Dec 2002 21:48:31 GMT Message-ID: <3DEE7832.3070500@ehatchersolutions.com> Date: Wed, 04 Dec 2002 16:48:34 -0500 From: Erik Hatcher User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: [Antidote] ToDo References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Craig Campbell wrote: > Cristoph and Eric, > > >> Will we introspect the buildfiles for tags to look >> for custom tasks...? > > > Introspecting the buildfiles for taskdef might not be a bad idea. If > we implement that solution, we can later expand it to link [...]/> tags to their buildfile or directory, as well as [...]/> tags to their respective targets? Just a thought. > > >> Have you seen the DTDs in Antidote, which are used as >> taskdefinitions currently? Can we use Erics approach to generate >> such DTDs or would you prefer another solution? The XDoclet stuff will be able to generate whatever metadata you want... we'd just have to have a template for the DTD, just like we have a template for the XML now. > I did see the DTDs and used them for each successive build I have > done, but consistently ran into the problem of custom tasks not > showing the children they excepted or the fields they had available > (when the customizer could not find the class and had to use the > table view). I agree that Eric's approach will be better and will > generate the necessary DTDs much more efficiently than AntStructure. > However, this will require (at least I think) that we implement the > xdocs stuff in antidote for the above solution. We > would need a shipping version of xdocs (or am I running down the > wrong path)? What I'd like to see is that task "libraries" get packaged as such, similar to how XDoclet "modules" get packaged as JAR files with a mandatory metadata file in them (xtags.xml, I believe). This makes them have to provide some information that the rest of the world can see. The builders of such task libraries would be responsible for creating that, either with XDoclet or by hand or any means they choose. Perhaps its a bit too strong to mandate that tasks be shipped this way, but at least ones that wanted to play nicely with IDE's and tools like Antidote. Thoughts? > Let me know if this is a possible solution: Require the creator of a > custom task to build a DTD for their task, by using the [...]/>, which would place the resulting files in a common directory > that Antidote would look in when it encounters a ? Oh, I just said that! :) Bingo. DTD's are out... old school, though. They should create an XML file that adheres to our schema/DTD though. > Unfortunately, the only solution that I have implemented has to to > with BeanInfo objects, and not the individual tasks. However, just > to be clear, what you would like to see is a custom icon for , > , , etc... ? I guess our Ant task "library" spec must include the ability to embed an icon for each task too :)) > Again, these are just some ideas on how to best meet the needs of the > problem. Let me know if I am way off. You're right on, as far as I can tell. Erik -- To unsubscribe, e-mail: For additional commands, e-mail: