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]>
