On 27 Mar 2001 10:42:06 +0200, Stefan Bodewig wrote:

>Stefan Bodewig <bodewig@apache.org> 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
>matching.
>

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

<copy>
  <fileset>
    <PatternCuller>
      <include name="afile.txt" />
    </PatternCuller>
  </fileset>
<copy>

becomes:

<copy>
      <include name="afile.txt" />
</copy>

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
>types.
>

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


>> * 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
>
>+1
>
>> * 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?

d