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 tasks into ${nant.location}, as opposed to just keeping
our customizations in their own place(s) and letting taskdef to its
thing on project-by-project basis. (eg: What if I have diffent versions
of MyCustomTasks.dll to use with diverse projects?)
What I'm looking at adding is an additional setting in the config file which is a list of folders to look for task assemblies in. This way you can just point this to wherever your custom tasks are located. In addition it would be possible to add to this folder list from a build file meaning that you could add tasks on a project basis.
Basically, there's no gain in not having it in the core, just a loss.Well it could be argued that having both methods adds confusion - which one should a new user use ?
It's wonderful magic that dropping *tasks.dll in ${nant.location} makes
things go, but it shouldn't be the only means of extensibility, as it
forces users to jump through hoops when they upgrade Nant.
Personally I find the taskdef mechanism a bit clunky for NAnt. Why should you have to specify a taskname and an assembly when you can just have nant scan for tasks automatically.
Is copying a couple of files really jumping thru hoops ? The config file options I mentioned above would eliminate this step anyway.
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
