Thanks for the perspective.
It turns out that in a lot of our users' build files a single task or a
combination of tasks has to be invoked repeatedly with different
combinations of parameters. As I'm just feeling my way into C# right
now (don't ask) I think that this will become even more true
On Tue, 20 Jan 2004, Mitch Denny <[EMAIL PROTECTED]> wrote:
> It is, in fact I spoke to Ian about it last week and he pointed me
> at your blog entries on the subject.
Which are certainly not the full story.
> Can you recall the justifications made for the element?
The Ant and NAnt communities
Having support for our own FileInfo+URI object could be useful. This would
support either relative file paths, or uris. It would resolve them and
provide useful information if there were errors. We already do this in
places, and having this code in one place where tasks could use it would be
a plus
On Tue, 20 Jan 2004 16:17:21 +0100, "Jaroslaw Kowalski"
<[EMAIL PROTECTED]> wrote:
>1. Make fail on attempts to define fileset when fileset with the
>specified "id" already exists.
I would prefer that re-defining a fileset with an already existing id
simple re-defined that fileset. It's a pain t
Sorry for my previous example. The resulting fileset should be empty because
files cannot be both "xxx.*" and "AAA.*".
Jarek
> the resulting fileset is (in terms of the set algebra, + means union, -
> means difference)
>
> L1 + L2 - (L3 - L4)
>
> so (because we're excluding almost every file but
> I think this is sufficient in 99.9% scenarios so if we don't find merge be
> useful we could always implement this [I have it in some state already]
> Should such implementation include even excludes from referenced fileset?
I suggest the following evaluation semantics:
> I think this is sufficient in 99.9% scenarios so if we don't find merge be
> useful we could always implement this [I have it in some state already]
> Should such implementation include even excludes from referenced fileset?
I suggest the following evaluation semantics:
> Not in current implementation. I dont like it much - using both id and
refid
> is little opaque...
>
> Better to introduce what you suggest in previous mail:
>
>
>
>
To be more readable, I would:
1. Make fail on attempts to define fileset when fileset with the
specified "id" alread
> BTW. Can you have this? (both reference a named fileset and re-define it
?)
>
>
>
>
>
> Jarek
Not in current implementation. I dont like it much - using both id and refid
is little opaque...
Better to introduce what you suggest in previous mail:
This does merge simmilary to
BTW. Can you have this? (both reference a named fileset and re-define it ?)
Jarek
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. F
> 3. Maybe we should start by implementing it the simple way: Make
"includes"
> and "excludes" support filesets (both referenced and nested):
>
>
>
>
>
>
>
>
>
>
>
>
>
> Perhaps it would be more efficient to hold off on the patch until more
> people have provided feedback, and until we've decided it in more detail.
> I'd hate to see your efforts go to waste ...
My 0.02 PLN:
1. I don't think merging can be done in a generic way (neither on xml level
nor at the o
- Original Message -
From: "Martin Aliger" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean"
<[EMAIL PROTECTED]>
Cc: "! nant" <[EMAIL PROTECTED]>
Sent: Tuesday, January 20, 2004 10:35 AM
Subject: Re: [nant-dev] types merging
> > I still think we should use xml mer
> I still think we should use xml merging (of both child nodes and
attributes,
> not only child nodes) for all types and not deal with filsets differently
> ...
It will be nice, but how to do e.g. ?
> I also don't think we should actually initialize the global types when we
Hi Gert and thanks for comments,
> Some small remarks :
>
> 1. I'm not sure there should be a Verbosity property on Element, why do
you
> think there should be one ?
Main reason - easy to implement and accessible everywhere (all tasks, all
types). If it is problem, we could move it into Task ins
> I already asked Jarek to correct the permissions (or just remove all files
> and directories in nightly/help altogether), but he hasn't responded yet
...
> The permissions set by the nightly build process should be ok, so I assume
> Jarek manually set the permissions ...
Sorry Gert, I didn't kno
16 matches
Mail list logo
