> From: James Duncan Davidson [mailto:[EMAIL PROTECTED]
>
> On 11/13/00 6:03 PM, "Jose Alberto Fernandez"
> <[EMAIL PROTECTED]>
> 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.
