----- Original Message ----- 
From: "Martin Aliger" <[EMAIL PROTECTED]>
To: "'Gert Driesen'" <[EMAIL PROTECTED]>; "'! nant'"
<[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 11:41 AM
Subject: RE: [nant-dev] extending pre-defined fileset


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

yeah, hold off until we get more feedback.

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

Scan() on parent fileset would also perform scan on nested filesets and
include results in parent fileset. That's what you're saying, right ?

For tasks like <zip> support for multiple top level filesets is still better
because files and directory in the zip file will have a name that is the
relative path to the base directory :

Using the following filesets :

<fileset basedir="c:\test">
    <include name="**/*" />
</fileset>

<fileset basedir="d:\test2">
    <include name="**/*" />
</fileset>

c:\
    test\
        file.txt
        subdir1\
            file.txt
d:\test2
    file2.txt
    subdir2\
        file.txt

would then lead to the following zip file :

file.txt
file2.txt
subdir1\file.txt
subdir2\file.txt

You cannot accomplish this using nested filesets.

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

Yeah, was hoping to find time to implement this, but things aren't looking
very good ;-)

Gert


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to