ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 21:50:30 GMT
> From: James Duncan Davidson [mailto:duncan@x180.com]
> 
> On 11/13/00 6:03 PM, "Jose  Alberto Fernandez" 
> <JFernandez@viquity.com>
> wrote:
> 
> > but I degress... The point is to give <taskdef> and <datadef> enough
> > expresive power such that there is no magic required for 
> anything else.
> 
> Good points -- I'm not sure that it makes since *not* to have 
> automatically
> defined tasks in the system (javac, jar, copy, etc) at 
> runtime. I don't
> think that making everybody call out the definition for the 
> javac task in a
> taskdef is good -- but the mechanism for those tasks should 
> be the same as
> for any other task. IE, the only thing that differentiates a 
> "built-in" task
> from a "external" task is it's location in the task lookup 
> hierarchy (in a
> place that gets setup when Ant is run) and that the built in 
> ones ship with
> the distribution. The mechanics should all be the same.
> 

I think is Nico's proposal for tasklib.xml descriptions of tasks on a JAR
that already eliminates the need for default.properties and for 
<taskdef> declarations in the build.xml.

In his architecture, the CORE goes on ANT's classpath and looks for
META-INF/tasklib.xml files in the JARs in the path. That file contains
the declarations contained in that JAR as <taskdef> declarations.
This rules apply for ant.jar itself. So the only primitives CORE
needs to understand is <taskdef> <datadef> (which is my new addition)
and the <tasklib> DTD itself.

                  
Jose Alberto
P.S.: I will post some ideas on how to deal with magic properties later.

Mime
View raw message