ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [VOTE] Datatypes
Date Thu, 12 Apr 2001 07:19:22 GMT
Stefan Bodewig <> wrote:

> * Allow mappers to be genericised so that particular features can be
>   modified during mapping. Something similar to

-1 on using mappers, +1 on defining a better way to attach attributes
to filesets.

> * Allow include/exclude tow work with multiple characteristerics of
>   a file.

+1 but keep a simple syntax for pattern matching.

> * provide datatypes through property tag and remove need for
>   separate free standing entities.

-0, i.e. I don't care to much and don't see much point in it.

> * provide support for non-hardwired (ie loadable) low-level 
>   components (mappers/itemset-filters/converters).
> * provide support for non-hardwired (ie loadable) converters.

+1 on making things more pluggable, we'll have to define the details
in the design phase.

> * Make all datatypes interfaces to allow them to be customized in
>   many ways.

-1 for that generalized form.

We can make them interfaces if we don't need a contract that is
stronger than method names.  In the case of <path> we have a stronger
contract (build.sysclasspath handling) right now, but this might
change if we spread responsibility in a different way.

> * Set arithmetic for fileset/patternset/*set


> * inheritance of ant properties/datatypes/context etc in project
>   hierarchy

+1 - and is a result of the unified namespace.

> * inheritance of between ant datatypes. ie fileset A inherits from
>   fileset B (includes all entries in A).

Here inheritance still seems to imply set union, no reason to have it
as a separate and ambiguos point. -1

> * Homogenize notion of PATHs and filesets

-1, path is ordered, fileset is not - and they should stay that way.


View raw message