RE: [nant-dev] extending pre-defined fileset

[Martin A. <mar...@go...>]

> We could just go for a nested fileset element after all. I'm 
> implementing
> something similar for a type called <path> or <pathset> 
> (similar to the Ant
> <path> element). Meaning :
> 
> <fileset id="...">
>     <fileset refid="...." />
>     <include name="..." />
> </fileset>

ok. I could implment this if community agrees.
 
> But that might ofcourse cause problems for tasks where the 
> relative path of
> the files is determined (relative to the base directory of 
> the fileset). For

I see only way - Scan() on original fileset and add full paths of found
files into new set. Could there be a problem with this approach?
Relative paths should be ok in this case, I hope.

Of couse - it is not the same to write
<fileset>
  <include name="*.*"/>
  <fileset>
    <exclude name="a.*"/>
 </fileset>
</fileset>

and 

<fileset>
  <include name="*.*"/>
  <exclude name="a.*"/>
</fileset> 

But it sounds logical to me.

> some (most?) tasks, it makes more sense to support multiple toplevel
> filesets.

Hmm. What I need it for, is to extend existing fileset to some more patterns
depending on some conditions, foreaches, etc. (not simple if/unless).
Multiple toplevel filesets will not help me it this case.

Only workaround I came with (and dont like) is to echo (append) all files I
want to have in fileset into temp file and then use <includesfile>.


> > btw: includes->include but includesList->includesfile? IMHO 
> "includefile"

>hat was done to match Ant.  Which is, as always, not really a goal by
> itself, but I'm very bad at coming up with names, so I trust 
> the Ant devs

ok.
As I looked into Ant docs I found interesting that Selector idea. Is there
any plan to port it into NAnt? (post release of course)
http://ant.apache.org/manual/CoreTypes/fileset.html

Martin