RE: [nant-dev] NAnt Namespaces
First, the proprietary method, not using any special xml features... the way Ant decided not to go. To demonstrate using the above example: loadtasks assembly=ImageFoo.dll namespace=ifoo / loadtasks assembly=NAntFileMagic.dll namespace=magic / ifoo:compress-image ... / Pros: * Concise * Single definition of namespace * No confusing uris, with no purpose other than as a name Cons: * Not valid xml (undeclared namespace?). Xml validation errors can be removed by declaring the namespace (xmlns:ifoo=http://tempuri.org/ifoo;) somewhere in the build file, but it's annoying to have to. -1 for this solution (or -maximum mine votes if I could give more (less?) than -1 :-) xml validity is _must_ at any case (we will be unable to parse it anyway!) Second, use namespaces more as they were intended (As I interpret the intention for xml namespaces). Using the same example: ifoo:compress-image xmlns:ifoo=assembly:ImageFoo.dll ... /[1] Pros: * Single definition of namespace * The namespace uri is meaningful cons: * The namespace has side-effects, being loading of tasks, functions etc. Hmm. Dont like this much too... btw: what is BAD about Ant's solution? That second repetition of namespace uri? I dont think that namespaces will be wide spread in all .build files, so I dont see anything more verbose bad here. Martin --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt Namespaces
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? First cut of the page is up at http://nant.sourceforge.net/wiki/index.php/NamespaceDesign It currently doesn't have anything other than other than what's already been in email. And possibly not even that. Is it worth publicising the link on the users list, for discussion/requirements purposes? -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 is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt Namespaces
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? [Conflicting task scenary] Yes, you're right. I just haven't thought of this yet. 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. May the proposed namespace attribute be a compronmise between convenience and too long namespaces? -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- 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
RE: [nant-dev] NAnt Namespaces
-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
Re: [nant-dev] NAnt Namespaces
Hi, * Troy Laurin wrote on 13.07.2004 (15:57): 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. On my way to work, I thought on my proposal. I wouldn't use a seperate attribute but changing the task attribute instead. The pro is, that we can rely that there *is* a namespace associated with each task. The con is, that it would require a rework on all tasks. A second con came into my mind, but it left as fast as it came: Giving all nant tasks a namespace would require a nant:csc.../nant:csc instead of csc.../csc. To avoid this, give the project a property defaultnamespace which is set to nant per default, but may be overriden by the user. 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? I don't have a problem discussing it here or on the wiki. Just tell me where discussion is running ;) -sa -- sa at programmers-world dot com http://www.livingit.de Internet sites: http://www.not2long.net - Make long links short Boomarks online: http://www.mobile-bookmarks.info --- 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
FW: [nant-dev] NAnt Namespaces
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaroslaw Kowalski My vote: let's NOT support it - I'd say more - let's disallow it. Simplicity is an important thing. The only advantage of XML namespaces I see is technical beauty and XSD schema support for extensible intellisense - IMHO it's not worth it. The main reason for implementing namespaces isn't elegance or schema support... funnily enough, it's for namespaces :-) Lets say you use various third-party libraries containing tasks for NAnt. The ImageFoo library contains a task compress-image, which takes a bitmap file and converts it to a jpg, with attributes to specify compression levels and such. One day, you find that you need to use the NAntFileMagic library, which also contains a compress-image task... this one takes a fileset of images of any format, and creates a multiple-page png file which is gzip-encoded (for example... does png even support multiple images per file? (-; ) Without namespaces, you can't (realistically) use these libraries together. However, if you could explicitly namespace each library, then you can unambiguously use all of the features of both libraries. For example (using namespace syntax similar to Ant): loadtasks assembly=ImageFoo.dll uri=http://tempuri.org/imagefoo; / loadtasks assembly=NAntFileMagic.dll uri=http://tempuri.org/file-magic; / ifoo:compress-image xmlns:ifoo=http://tempuri.org/imagefoo; ... / Having said all of this, I tend to agree with Jarek in that namespaces aren't a particularly good way of doing this... at least, not the way Ant does it. Particularly clumsy is the need to specify the URI at least twice. I can see two obvious alternative syntaxes that are cleaner than the above. Note that they are put here for comment, I'm not necessarily recommending either of these approaches. First, the proprietary method, not using any special xml features... the way Ant decided not to go. To demonstrate using the above example: loadtasks assembly=ImageFoo.dll namespace=ifoo / loadtasks assembly=NAntFileMagic.dll namespace=magic / ifoo:compress-image ... / Pros: * Concise * Single definition of namespace * No confusing uris, with no purpose other than as a name Cons: * Not valid xml (undeclared namespace?). Xml validation errors can be removed by declaring the namespace (xmlns:ifoo=http://tempuri.org/ifoo;) somewhere in the build file, but it's annoying to have to. Second, use namespaces more as they were intended (As I interpret the intention for xml namespaces). Using the same example: ifoo:compress-image xmlns:ifoo=assembly:ImageFoo.dll ... /[1] Pros: * Single definition of namespace * The namespace uri is meaningful cons: * The namespace has side-effects, being loading of tasks, functions etc. There's actually an extra issue in using namespaces in a fashion similar to xml namespaces, whatever the approach... In (my understanding of) the current behaviour of loadtasks, any loaded tasks are available at any point in the build system that occurs after the task executes. Xml namespaces, on the other hand, are only visible in the defining element and all children. While this itself isn't a major problem, it lends itself to the concept of *redefining* a namespace... so a child element could redefine the namespace with a different assembly - once the child element has completed executing, the namespace returns to the parent's definition. This is probably a really bad idea, because it would be hard to understand or maintain build files. But if a build definition were spread across multiple included and called files, and if different people author various files, it's not an impossible circumstance. Finally, would this concept of namespaces introduced to tasks replace, extend, or not affect the current concept of namespace in functions? ie- load an assembly containing functions, specify the namespace 'myfoo'. If the assembly contains a function mystring::to-lower-case, would the function then be referenced by myfoo::mystring::to-lower-case? Also, I imagine that the use of namespaces may make the schema task more difficult to maintain, depending on the implementation chosen... Regards, -- Troy 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.
RE: [nant-dev] NAnt Namespaces
-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
[nant-dev] NAnt Namespaces
Hi, Currently the NAnt support for namespaces is very limited, definitely when compared to Ant (http://ant.apache.org/manual/CoreTypes/namespace.html). Just want to get the discussion on this topic going ... Gert --- 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
Re: [nant-dev] NAnt Namespaces
My vote: let's NOT support it - I'd say more - let's disallow it. Simplicity is an important thing. The only advantage of XML namespaces I see is technical beauty and XSD schema support for extensible intellisense - IMHO it's not worth it. From my experience I can say that it's really difficult to explain the concept of XML namespaces and URNs to first-time users of XML. Based on this, I think that using URIs as xml namespaces is the most confusing thing on the planet (what? there's no file under http://tempuri.org/;) . Most people are well off without namespaces. XSDs can be generated usign schema task today, and I think it's good enough for most cases. Jarek - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: Nant-Developers (E-Mail) [EMAIL PROTECTED] Sent: Sunday, July 11, 2004 11:58 AM Subject: [nant-dev] NAnt Namespaces Hi, Currently the NAnt support for namespaces is very limited, definitely when compared to Ant (http://ant.apache.org/manual/CoreTypes/namespace.html). Just want to get the discussion on this topic going ... Gert --- 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 --- 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
