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 know
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
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
3. Maybe we should start by implementing it the simple way: Make
includes
and excludes support filesets (both referenced and nested):
fileset basedir=dir.a
includes file=aaa.txt /
includes fileset=r1 /
includes
fileset basedir=dir.b
BTW. Can you have this? (both reference a named fileset and re-define it ?)
fileset id=aaa refid=aaa
includes name=*.* /
/fileset
Jarek
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development
BTW. Can you have this? (both reference a named fileset and re-define it
?)
fileset id=aaa refid=aaa
includes name=*.* /
/fileset
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
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:
fileset id=aaa
includes refid=aaa /
includes name=*.* /
/fileset
To be more readable, I would:
1. Make fileset fail on attempts
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:
fileset
includes
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:
fileset
includes
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 AAA.*)
On Tue, 20 Jan 2004 16:17:21 +0100, Jaroslaw Kowalski
[EMAIL PROTECTED] wrote:
1. Make fileset 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
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
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 have
Thanks for the perspective.
quote source=Stefan
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
14 matches
Mail list logo
