What if we allow all tasks (as opposed to just properties and taskdefs) to
be used outside of targets , and execute them on the spot? They would be
similar to "static {...}" blocks in java, in that they get run as soon as
the class/project is loaded. So at the top of your build file you could
just put the following, which would cause the javac task to run before the
taskdef:
<project name="foo">
<javac srcdir="lib" destdir="lib"/>
<taskdef name="xslt" classname="Xslt" classpath="lib"/>
<target name="bar">
...
Or, if we decide to wait until execution time to instantiate tasks, we
could add a "target" attribute to taskdef, which would cause that target to
be built before loading the task class:
<project name="foo>
<taskdef name="xslt" classname="Xslt" classpath="lib" target
="xslt-compile"/>
<target name="xslt-compile">
<javac srcdir="lib" destdir="lib"/>
</target>
...
Using this system, we can avoid compiling the task until we actually need
to use it.
Matt Foemmel
ThoughtWorks, Inc.
[EMAIL PROTECTED]
com To: [EMAIL PROTECTED]
cc:
06/18/2000 Subject: Re: [RFE] Richer Task
Specification
07:23 AM
Please
respond to
ant-dev
duncan wrote:
> > Nested taskdef elements, with identical syntax to the current taskdef
> > task, could be used to generate the necessary <include> statements on
> > the javac and then to define the mapping between classname and task
> > name. Users could obviously add their own <include> statements if
> > necessary.
>
> Could you propose a sample of how this would be stated in XML?
Here is a sample that could be useful in xml-fop:
<compileTask srcdir="lib" destdir="lib">
<taskdef name="xslt" classname="Xslt" />
</compileTask>
- Sam Ruby
P.S. In order to further the discussion, I'm committing in an untested
implementation. Monday(-ish) I'll test it and contribute documentation
(unless somebody wishes to beat me to it).
