On 27 Mar 2001 10:42:06 +0200, Stefan Bodewig wrote:
>Stefan Bodewig <[EMAIL PROTECTED]> 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
