On May 12, 2005, at 4:59 PM, Mike Kienenberger wrote:
> Erik Hatcher <eri..hatchersolutions.com> wrote:
>
>> Why does your task use filesets when the purpose is to compare dir1
>> and dir2? You could internally create a Fileset if that makes
>> walking a directory more convenient, but I'm not seeing what benefit
>> allowing <fileset> under this task provides.
>>
>
> I started off comparing existing generated classes with my newly-
> generated
> classes, and some of those classes couldn't be compared because
> they were
> "touched up" (cayenne license info was added to them). They needed
> to be
> excluded.
>
> I eventually decided it made more sense to generate my own baseline
> comparisions (if for no other reason than we don't have any good
> single-class baselines).
>
> I left it in because it adds a lot of flexiblity at almost no usage
> cost. I
> suspect I'll make use of the task to do other things down the road.
> Ideally, I'd add in a default Fileset value of "**" to reduce the
> usage cost
> of the flexiblity to nil.
>
> So my self-justifying answer is that it's not a task for comparing
> directories. It's a task for comparing arbitrary filesets :)
However it doesn't actually compare <fileset>'s. It's comparing the
filenames found in the filesets, except using dir1 and dir2 as the
base directories. So the files in the filesets themselves may never
be compared - except that you're specifying the same directory for
your nested fileset as you use for one of the dir attributes.
So I'm not seeing the flexibility you say it adds.
Erik
This archive was generated by hypermail 2.0.0 : Thu May 12 2005 - 18:27:52 EDT