----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 26, 2001 5:57 PM
Subject: [DISC] Datatypes
> * Allow mappers to be genericised so that particular features can be
modified
> during mapping. Something similar to
>
> <fileset ...>
> <include name="*.sh"/>
> <mapper type="unix-permissions">
> <param name="user" value="ant"/>
> <param name="group" value="ant"/>
> <param name="mod" value="755"/>
> </mapper>
> </fileset>
>
-1, I am happy to have lots of different mappers, but I am not sure what we
mean by "genericise" here. My concern is how that affects other things such
as Filesets. The above example would require filesets to carry around a
whole set of Unix permissions, I guess. That makes filesets cumbersome
because somewhere else, someone will want NT ACLs, VMS doodahs, etc. Not
sure where it would end.
> * Allow include/exclude tow work with multiple characteristerics of a
file.
> ie include into fileset if file is readable, modified after 29th of Feb,
> has a name that matches patter "**/*.java" and the property
"foo.present"
> is set. Something similar to
>
> <include>
> <item-filter type="name" value="**/*.java"/>
> <item-filter type="permission" value="r"/>
>
> <!-- could optionally be directory/or some other system specific
features -->
> <item-filter type="type" value="file"/>
> <item-filter type="modify-time"
> operation="greater-than"
> value="29th Feb 2003"/>
> </include>
>
-0, I think we need to be careful about how much nesting is required for
common operations.
<javac>
<include>
<item-filter name="**/*.java"/>
<...>
is going to be verbose. Therefore I would like to see the current <include
name="..."> usage retained and <item-filters> as optional stuff, if
required.
> * provide datatypes through property tag and remove need for separate
free
> standing entities. ie
> <property name="foo">
> <fileset dir="blah">
> <include name="*/**.java" />
> </fileset>
> </property>
-1. While it is nice and goes with the unification of the namespaces, I
think it is verbose and loses something. People want to feel that they are
dealing with filesets, not properties which happen to be filesets. I would
like to keep <property> as the name of the string datatype.
>
> * provide support for non-hardwired (ie loadable) low-level
> components (mappers/itemset-filters/converters). Allow them to be
> loaded in either global or a new classloader.
-0, I'd need to see more on this to really know what it means.
>
> * provide support for non-hardwired (ie loadable) converters.
>
> Q: What is a converter? Is this an implementation detail?
> A: Not an implementation detail but a way to extend the engine
> to convert more data types. 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. This becomes particularly
> relevent if you build ant based testing systems and use ant in certain
> web-related areas.
-0 - I haven't seen the need for it much myself. I don't mind having it in
if it doesn't get in the way.
>
> * Make all datatypes interfaces to allow them to be customized in many
> ways.
-0, Not sure what the motivation for this. It also make the creation of
these more complex since we need to know the actual type to use for the
given interface. Not sure how that is going to be specified or whether I
ave misunderstood it all anyway.
>
> * Set arithmetic for fileset/patternset/*set
-0. OK in principle.
>
> * inheritance of ant properties/datatypes/context etc in project
hierarchy
-0. Is this static scoping versus dynamic scoping. Not sure what it would
mean but it does sound as if it may be complex, especially the interplay
between static and dynamic scope.
>
> * inheritance of between ant datatypes. ie fileset A inherits from
fileset B (includes
> all entries in A).
-0. I haven't seen the need for this yet.
>
> * Homogenize notion of PATHs and filesets.
-1. I have always seen filesets as unordered and paths as ordered. I think
there is a difference and no need to homogonize them.
>
>
