Stefan Bodewig wrote:
> * 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>
What exactly do we mean by "genericised?" Generic in the sense of "all tasks
can use
mappers," or "mappers can do anything?"
> * 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>
+1 if its optional; I think Conor has the right idea with this.
> * 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. If we unify the datatype namespaces so that ${foo} means .toString() of
the object
indicated by "foo", what do we need this for?
> * 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 like the idea, but I'd want to see a proposal for the implementation.
> * 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.
This point is actually covered by the previous one.
> * Make all datatypes interfaces to allow them to be customized in many
> ways.
+0
> * Set arithmetic for fileset/patternset/*set
+1
> * inheritance of ant properties/datatypes/context etc in project hierarchy
+1 if we come up with an agreement on how scoping works.
> * inheritance of between ant datatypes. ie fileset A inherits from fileset B
> (includes
> all entries in A).
-1. I think this would unecessarily complicate datatypes.
> * Homogenize notion of PATHs and filesets.
I though PATHs are an ordered listing of directories while filesets are
unordered
collections of file names. What's to homogenize? They are two distinct
concepts as far
as I'm concerned.
Glenn
