Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 71717 invoked from network); 7 Jan 2003 17:57:18 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 7 Jan 2003 17:57:18 -0000 Received: (qmail 4362 invoked by uid 97); 7 Jan 2003 17:58:13 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 4233 invoked by uid 97); 7 Jan 2003 17:58:12 -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 4156 invoked by uid 98); 7 Jan 2003 17:58:11 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Injected-Via-Gmane: http://gmane.org/ To: ant-dev@jakarta.apache.org Path: not-for-mail From: Costin Manolache Subject: RE: Antlib... when? Date: Tue, 07 Jan 2003 09:48:13 -0800 Lines: 69 Message-ID: References: <747F247264ECE34CA60E323FEF0CCC0C0F50A3@london.cellectivity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@main.gmane.org User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jose Alberto Fernandez wrote: >> > Several of the issues exposed here like what to do about redefining >> > tasks and so on where addressed on the proposal in the >> /antlib/ which >> > I wrote. >> >> My primary concern with this particular proposal - the XML >> descriptor. >> I'm fine with it as long as a simple antlib is also supported, using >> .properties. >> > > The main issue with this is that it needs to support declaring tasks > and datatypes, so a simple .properties would not do. At the moment the distinction between tasks and datatypes is almost gone. If you really want to keep the separated - we could use 2 properties, one for tasks and one for datatypes. I think it would be quite easy to remove the last remaining distinction - at least for new antlibs. It's not very hard and if done only for new antlibs it won't affect backward compat. We just need to treat all antlibs as components. If a component implements Task - it'll be a task. If not - it'll not be wrapped in TaskAdapter ( as a task would be ) unless it has an execute() method. That will mean that any datatype that is included in an antlib will have the additional restriction - no execute() method. > On the otherhand, the proposal came with a nice task that could > be made to generate the XML for you based on some simpler description. > So it does not have to be dificult. The fact that you have tools doesn't mean it's simple or easy - quite the contrary :-) There is also the overhead of parsing dozens of XML files, understanding and explaining all the elements. Also the danger of future model complexity and raising the bar. Again - I have no problem with using XML for advanced antlibs where it may be really needed. But I'll strongly opose not having the "simple" option. Especially since many "taskdef" libs use properties file already, and the concept is widely understood. >> There is also the issue of automatic loading of antlibs >> versus explicit >> declaration. At least Conor and me ( convinced by Conor ) expressed >> a preference to explicit. >> > > To me the reason for automatic loading is to allow ANT core itself > to use and to load. I would hate having two different mechanisms > one for core and one for non-core. Whether the autoload libraries > are "discovered" or explicitly mentioned somewhere is a separate issue. The loading for the core tasks works fine. And we would have the same mechanism for core and for simple antlibs - the same properties file ( or 2 if we want to keep types separated ). Costin -- To unsubscribe, e-mail: For additional commands, e-mail: