>I'm not sure that multiple filesets in a single copy task is much better
>than multiple copy tasks.
Here's why I think its more than a slight improvement:
The core problem is duplication. I finished the refactoring that lead to
my OP and here's where it stands:
The goal is to copy assemblies from two build locations to six web
projects.
Four filesets common enough to be extracted (called foo.one foo.two
bar.one bar.two, where foo is location A, and bar is location B)
I still have some duplication -- some project copies look like this:
<copy todir="${project.six.out.dir}">
<fileset refid="foo.one" />
</copy>
<copy todir="${project.six.out.dir}">
<fileset refid="foo.two" />
</copy>
<copy todir="${project.six.out.dir}">
<fileset basedir="${lib}">
<includes name="${foo.namespace}.more.dll" />
<includes name="${foo.namespace}.assemblies.dll" />
<includes name="${foo.namespace}.not.dll" />
<includes name="${foo.namespace}.common.dll" />
</fileset>
</copy>
<copy todir="${project.six.out.dir}">
<fileset basedir="${project.build.out}">
<includes name="${bar.namespace}.still.dll" />
... (10 more not totally common assemblies)
<includes name="${bar.namespace}.more.dll" />
</fileset>
</copy>
So the result is no obviouis cohesion between those four copy tasks --
except their todir (which is duplication, and thus a maintenance issue)
In total I have 18 copy tasks to set up the 6 web projects
Worse, some of the "not duplicated files" are duplicated, but factoring
them out into still more copy tasks *and* filesets made the build file
unreadable. If instead I could just construct one copy for each project
using a series of filesets, some factored out duplicates, and others just
included, it would make things a lot more readeable, easier to maintain,
and less likely to get factored apart. Right now I have to rely on
comments.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
idia ktesis, koine chresis
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
