>
>
>
> or
>
>
>
>
>
>
>
> What do you guys think?
OK. I know get the place of in the story and it makes
complete sense to me. Lose the old . Man, what a dud! :)
A single file or a fileset makes sense also.
>From your example, I can't tell whether the path= attribute is for a
s
Jean Rajotte wrote:
Ian, Tomas,
1) I prefer to because the name hides the
implementation (I shouldn't care when the task gets loaded).
but you do want those tasks loaded at that point - it would be useful to
have it log which tasks its found for debugging purposes.
2) I see Tomas echoes my co
Jean Rajotte wrote:
Really? A single, centralized config file would handle all my projects'
quirky requirements. I didn't get that from your schema. I still think
it's easier in some case to handle it on a project by project basis and
taskdef does that for me.
the load tasks proposal is on a pr
Tomas Restrepo wrote:
Jean,
Basically, the same as Ian proposes, but I'd have loadtasks examine the
contents and see if it references a file or a directory: if the former, just
load that one and that's it; otherwise scan for task assemblies. This would
give us all the functionality of the old Tas
Jean,
> I think tomas was saying there's no gain in losing taskdef, only loss,
> like my point.
True. But the alternative Ian proposes sounds good, as it
accomplishes the same as taskdef, but does it in a more nant-like way. I'm
happy to change a line or two in my buildfiles for this.
My only a
> > 1) I prefer to because the name hides the
> > implementation (I shouldn't care when the task gets loaded).
> but you do want those tasks loaded at that point - it would
> be useful to
> have it log which tasks its found for debugging purposes.
OK. I get it. Loadtasks is a better name.
Tomas Restrepo wrote:
That's cool. However, allow me to present an "alternative" point of view:
Why can't we have *both*? The argument I've been hearing since taskdef was
shunned (and I'm one of the ones that complained about this at the time) is
that the config stuff is more flexible and more ele
Ian, Tomas,
1) I prefer to because the name hides the
implementation (I shouldn't care when the task gets loaded).
2) I see Tomas echoes my concern in spades. "so what" if it's Ant-like
and klunky. It's just another tool. It doesn't preclude the
and the config file approaches. It just adds
Hi Ian, Jean,
Allow me to join this briefly... I'll let you guys return to your regularly
scheduled program afterwards :)
> >>Personally I find the taskdef mechanism a bit clunky for NAnt.
> OK to be more clear - the way taskdef works derives from the ant model
> where you have to register every
Jean Rajotte wrote:
Ian,
First, thanks for humoring me on this. I'm not sure whether I should
apologize for going on about this. I'm new here. My original impetus
for joining the list was that taskdef is exactly what I wanted and I
couldn't find it w/o hassle.
thats ok. You seem to have a valid
Ian,
First, thanks for humoring me on this. I'm not sure whether I should
apologize for going on about this. I'm new here. My original impetus
for joining the list was that taskdef is exactly what I wanted and I
couldn't find it w/o hassle.
> What I'm looking at adding is an additional setting
Ian,
Thanks for your reply. I understand the mechanics "integrating" my
tasks to the ${nant.location}, but it's beside the point. It seems to
me it's wrong-headed to deprecate a means of extensibility. It means
that anyone who upgrades NAnt HAS TO do something(s) extra in order to
re-drop their
Jean Rajotte wrote:
Ian,
Thanks for your reply. I understand the mechanics "integrating" my
tasks to the ${nant.location}, but it's beside the point. It seems to
me it's wrong-headed to deprecate a means of extensibility. It means
that anyone who upgrades NAnt HAS TO do something(s) extra in ord
CTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, April 01, 2003 4:47 PM
Subject: Re: [Nant-users] IMHO, Taskdef doesn't belong in nantcontrib
[snip]
> we should probably update the examples in that case.
-
Jean,
the reason its in nantcontrib is because its deprecated. To add new
tasks all you need to is drop the new task assembly in the same folder
as nant and it will *automatically* find all the tasks in it. See the
FAQ [1] and the "Writing a custom NAnt task " turorial[2] on the wiki [3]
I just
15 matches
Mail list logo
