> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Sascha Andres > > But don't we already have a possibility to decide what task > is used? My personal version task uses my namespace. So why > don't we give a task the complete name : namespace + > taskname. Tasks in NAnt.* namespaces would be referenced > without the namespace. And if there is no task xyz, tha tasks > name in the script wouldn't be namespace.xyz but xyz.
Are you suggesting using the namespace for the class implementing the task, when referencing the task in the build file? This seems like it could be excessively verbose, to me. Also, namespaces should also be always on or always off... I don't have any issues with leaving the nant core tasks to use the null namespace, but if a particular task is in namespace xyzzy, then it should always be referenced "xyzzy.foo" (or "xyzzy:foo", or whatever namespace identifier is used). If namespaces are optionally specified, then people won't (in general) use them unless there's a conflict in advance... and that means that in your example with the developer using his own concat task he wouldn't use the namespace because it doesn't conflict - which means that it will still fail when it conflicts with nant-contrib, or worse, it would accept the nant-contrib task in precedence and the build would perform strangely! I appreciate the need for convenience, but since namespaces are a tool for a correctness problem, it's not valid to compromise correctness for convenience. -T Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
