ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: [PATCH] User defined types and tasks to be loaded before default ones are...
Date Tue, 26 Nov 2002 20:18:16 GMT
----- Original Message -----
From: "Dominique Devienne" <>

> I don't understand why you need to load custom tasks/types before the Core
> tasks/types. The current mechanism for loading them seems OK to me
> <antlib> for a better mechanism though).

<antlib> or <rantlib>? ;-(

The problem as has been discussed before is that the
mechanism that currently exists to initialize default
tasks checks to see if users are using 'known'
nested elements.  Let us take <condition> for example:

    <condition property="filename" value="Windows NT">
      <os name="Windows NT"/>

Project.init will load up without any issues in the above
case.  Let us say, ConditionBase has been now modified
to accept dynamic user defined nested elements and one such
is <myos> which is very similar to <os>.  Soz, I would like
to define it as follows:
    <typedef name="myos" classname="..."/>
    <condition property="filename" value="Windows NT">
      <myos name="Windows NT"/>

Project.init would balk at this.  I think this can be resolved
by extending ConditionTask indirectly from UnknownElement, but I
am not so sure it is the right approach.

Therefore I find this approach of loading up certain
Tag->classname maps before the default ones to be fruitful.
If this were done, and myos is mapped to some class, then
the following would work (of course after modifying IH
and conditionbase)*

    <condition property="filename" value="Windows NT">
      <myos name="Windows NT"/>

> Also, you assume the custom tasks/types are defined in properties files,
> which preclude using resources inside JARs (I have a resource: custom URL
> protocol similar to JBoss' one which I believe Ant should have) as you
> currently can (which I use).

Oh, but you can always edit (types/tasks)/
and rejar it to get a similar effect.  But yes, you have
a valid point here - maybe instead of going with a file,
I may just use a URL (which may be file:// or jar://, etc.)
The basic idea is to help avoid having to edit
and rejar it.


(*) more on this on my next patch.

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

View raw message