ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: Adding a custom task to default.properties
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.

    Erik

----- Original Message -----
From: "Dominique Devienne" <DDevienne@lgc.com>
To: "'Ant Users List'" <ant-user@jakarta.apache.org>
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: David.Bailey@lawson.com [mailto:David.Bailey@lawson.com]
> Sent: Thursday, March 07, 2002 3:04 PM
> To: ant-user@jakarta.apache.org
> 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:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message