ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn McAllister <>
Subject Re: [DISC] Datatypes
Date Mon, 26 Mar 2001 15:04:51 GMT
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.


> * Set arithmetic for fileset/patternset/*set


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


View raw message