For now, you can do this: 1)Under your ant installation directory, create the following directory:
cd $ANT_HOME mkdir taskdefs 2)Extract the defaults.properties file from the lib/ant.jar into your taskdefs dir: cd taskdefs jar -xf ../lib/ant.jar org/apache/tools/ant/taskdefs/defaults.properties 3)Edit your ant.bat or ant.sh file to add taskdefs into your classpath before jakarta-ant.jar Now you can edit the defaults.properties in your taskdefs directory to add new task defs. Also, you can put your tasks in this directory so they're available to all projects that use that installation of ant. -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 4:57 PM To: Ant Users List Subject: Re: Adding a custom task to default.properties 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
