> -----Original Message-----
> From: Gert Driesen
> 
> I definitely agree with you here ... But I'm also convinced 
> that this is not something we can/should implement right now. 
>  Our focus right now is to get a stable NAnt 0.85 released.  
> It would ofcourse be interesting if someone could write a 
> small paper on this topic right now, or implement a small 
> proof-of-concept.
> 
> Gert

Without a doubt, an 0.85 release is the highest priority.

This might be something that I'd be interested in picking up, but I
wouldn't expect to be able to start on that until closer to the end of
the month... in the meantime, the requirements and desired semantics in
the build file can (should!) be worked out.

> -----Original Message-----
> From: Sascha Andres
> 
> Hi,
> * Troy Laurin wrote on 13.07.2004 (10:17):
> > 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.
> 
> Well, I always use a short namespace. So I actually don't thought that
it
> may get longer. What about using a task attribute
[TaskNamespace("Sascha")]
> which forces me to use <Sascha:TaskName>...</Sascha:TaskName>?
> 
> May the proposed namespace attribute be a compronmise between
convenience
> and too long namespaces?
> 
> -sa

Defining namespace in the class defining the task is an interesting idea
and a possible solution... it's worth comparing this with the other
viable solutions to see what's the best solution, both in terms of
functionality as well as correctness and convenience.

Rather than continuing this discussion (in particular, compare &
contrast) on this list, is it worth creating a page for the
requirements/semantics of namespace support to the nant wiki pages?


-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

Reply via email to