Re: [Nant-users] IMHO, Taskdef doesn't belong in nantcontrib

[Ian MacLean]

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

So I'd have to preserve "my" part of the config file when I update Nant,
instead of preserving my *Tasks.dll.  I'm not sure there's a gain.
or preserve the whole config file. Surely this would be necessary for 
any application that stores prefs in a config type file. Once we get a 
proper installer we could add the option to import settings from the 
previous installation.
Also I mentioned that I will add a way to set the search path from a 
build file which will give you equivalent functionality to taskdef - ie 
you can specify tasks from a buildfile and won't need to "Jump thru 
hoops" on a new install.
It seems to me that this will provide the same functionality as taskdef 
- would that satisfy your requirements ?


Also, is it me or is there a problem w/ the copying of the new build of
a customTasks.dll into ${Nant.Location} while nant is running, holding
the target dll?
this would be an issue whatever extension mechanism you use. If the file 
is locked and you try and overwrite it there will be problems.


Also also, my point is:  why subtract from Nant.Core?  Flexibility is
good. You say
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 task for it to be usable. Its also 
badly named - its not defining a task its merely telling nant where to 
find one. In addition, having to do a taskdef for every task in an 
assembly when there is a perfectly good discovery mechanism seems 
wasteful. Thats what I mean by clunky.

To each her own.  taskdef suits my entreprise's strategies better and I
don't understand the top-down decision of subtracting it from the core.
it was felt that taskdef was mapping ants task loading model and not 
that of NAnt. I'm thinking that the mechanism to set the search path 
from a build file would look somthing like :

<taskpath path="..\foo">
</taskpath>
or
<taskpath>
        <fileset>
                <includes name="..\foo" />
        </fileset>
</taskpath>
which would trigger a scan of matching folders for task assemblies.
what do you think ?
it seems to me that this is taskdef in different clothing - just using 
nants discovery model.

We've probably said enough at this point.  Again, thanks for your
persistence.
not a problem.

P.s., is it me or does this list hiccup? (I get many same messages).
reply-all will send to the list and the original poster meaning that 
they will see it twice.

Ian



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users