ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <>
Subject Re: [DISC] Datatypes
Date Tue, 27 Mar 2001 21:15:19 GMT
On 27 Mar 2001 10:42:06 +0200, Stefan Bodewig wrote:

>Stefan Bodewig <> wrote:
>>  * Allow mappers to be genericised so that particular features can
>>  * be modified during mapping.
>I don't see this as the purpose of a mapper. These attributes (like
>Unix file permissions) are decorations of the plain filesets, nothing
>that has any connection to the mapper concept at all.
>If this is only a means to get the decoration connected with the
>fileset, I'd prefer a different syntax.

I agree that mappers are used for filename mapping, not file
modification. Actually, mappers should be used for path modification.
I make the distinction because they should be applicable to a variety
of sources (file system, ftp, http, zip, etc.).

File modification should be handled by a task acting on a set.

>>  * Allow include/exclude tow work with multiple characteristerics of
>>  * a file.
>Generally +1, need to look into David's Culler proposal. But we need
>to provide a simplified syntax for the common case of file name

I agree. The question is if we should really support merging a certain
default nested element into its parent (like FileSet in Javac). So

      <include name="afile.txt" />


      <include name="afile.txt" />

Or possibly somewhere in between.

Or, if we like my idea of merging attributes and nested elements along
with "auto-sets":

<copy include="afile.txt" />

>> * provide support for non-hardwired (ie loadable) converters.
>>   Currently we have fixed set that is expanded on occasion (ie
>>   includes primitive types + File). Instead of spreading converting
>>   code through out tasks it can be centralized into one component
>>   and used by engine.
>But it isn't spread, it is centralized in IntrospectionHelper - but
>not pluggable. Do we need that much flexibility? People could simply
>implement a String argument constructor for their custom attribute

At the very least it needs to be refactored in IntrospectionHelper so
it can be reused outside of it. Perhaps simple static methods would

>> * Make all datatypes interfaces to allow them to be customized in
>> * many ways.
>Where appropriate, but not all of them.

Which ones do you not like?

>> * Set arithmetic for fileset/patternset/*set
>> * inheritance of ant properties/datatypes/context etc in project
>> * hierarchy
>comes for free with the unified namespace.
>> * inheritance of between ant datatypes. ie fileset A inherits from
>> * fileset B (includes all entries in A).
>If "(includes all entries in A)" is the description for inheritance
>here, this is covered by set arithmetic.
>> * Homogenize notion of PATHs and filesets.
>Doesn't always make sense, we need the specific use cases where paths
>and filesets are interchangeable.

When are they not?


View raw message