ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Adding a custom task to
Date Thu, 07 Mar 2002 21:56:58 GMT
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.


----- Original Message -----
From: "Dominique Devienne" <>
To: "'Ant Users List'" <>
Sent: Thursday, March 07, 2002 4:38 PM
Subject: RE: Adding a custom task to

> Or better yet, a true plugin architecture as someone recently wrote on
> 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
> 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
> the search greatly, by using the convention already used by ant
> **.ant.**.taskdefs.**, **.ant.**.types.**). I'm sure many people will
> 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
> URLs of the URLClassLoader, and scan these), and its pretty fast (.2
> for a really big classpath, on a fast and recent DELL/W2K). --DD
>  -----Original Message-----
> From: []
> Sent: Thursday, March 07, 2002 3:04 PM
> To:
> Subject: Adding a custom task to
> 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
> a
> <taskdef> statement in every build.xml which uses the task, or to modify
> the
> org/apache/tools/ant/taskdefs/
> 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
> ant.jar as a file which defines home-grown ant extensions?  Maybe call it
> 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:   <>
> For additional commands, e-mail: <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message