Dominique - hop over to ant-dev to talk about this further. Its already
under development as a proposal or two under the name "antlib".
But, one major caveat to your scheme: tasks and datatypes do not have to
extend from Task and DataType. The only thing that makes a task a task
ultimately is if it has an execute() method, for example.
Erik
----- Original Message -----
From: "Dominique Devienne" <[EMAIL PROTECTED]>
To: "'Ant Users List'" <[EMAIL PROTECTED]>
Sent: Thursday, March 07, 2002 4:38 PM
Subject: RE: Adding a custom task to default.properties
> Or better yet, a true plugin architecture as someone recently wrote on
this
> list. Just having custom tasks and types in the classpath should be enough
> for them to be picked up. And the actual task name (used in the XML build
> file) can even be specified using a public static final String, and
grabbed
> thanks to reflection. It's just the matter of scanning the classpath, and
> looking for concrete classes implementing Task and DataType. Search can be
> narrowed by loading only classes based on the package/class name (speeds
up
> the search greatly, by using the convention already used by ant
> **.ant.**.taskdefs.**, **.ant.**.types.**). I'm sure many people will
object
> to automagically add tasks/types, but that would make adding custom task
> real easy.
>
> I've done scanning of the classpath like described above recently (grabs
the
> URLs of the URLClassLoader, and scan these), and its pretty fast (.2
seconds
> for a really big classpath, on a fast and recent DELL/W2K). --DD
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 07, 2002 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: Adding a custom task to default.properties
>
>
> A request . . . .
>
> I believe that the only two ways of defining the association between a
> custom
> ant task and the class which contains the logic for the task are to
include
> a
> <taskdef> statement in every build.xml which uses the task, or to modify
> the
> org/apache/tools/ant/taskdefs/default.properties.
>
> Including a <taskdef> in every build file can get tedious, especially if
> one
> defines many custom tasks. But there are good reasons why we don't want
> to munge ANY of the contents of ant.jar (mainly because of the headaches
> that would create in making sure that we get a modified ant.jar into the
> hands
> of every customer who needs one, and so that some customer doesn't
> decide to upgrade ant on their own and download a copy from Jakarta, thus
> losing our custom task definitions, etc.).
>
> Any hope of teaching ant to recognize a .properties file which lives
> OUTSIDE
> ant.jar as a file which defines home-grown ant extensions? Maybe call it
> extensions.properties or something? Or perhaps better still, define a
> 'custom.task.defs' property which we can set and thus specify our own
> .properties
> file?
>
> Thanks for your consideration,
>
> --dave
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
