[nant-dev] Re: [Nant-users] NAnt 0.85 release notes + to-do's
Hi Gary, Thanks for the feedback. I've updated the description of this breaking change as follows : In previous versions of NAnt, the arg element (used by, for example, the exec task) would automatically add quotes for both file and value attributes in the command line generated by the task. That automatic quoting has been removed for value attributes (but not for file attributes). This change may break build files that assume that both arguments specified using the file and value attributes will automatically be quoted. Is this ok for you ? Gert - Original Message - From: Gary Feldman [EMAIL PROTECTED] To: Nant-Developers (E-Mail) [EMAIL PROTECTED]; NAnt Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 2:51 PM Subject: Re: [Nant-users] NAnt 0.85 release notes + to-do's From: Gert Driesen [EMAIL PROTECTED] Sent: Monday, August 02, 2004 4:28 PM The release notes for the NAnt 0.85 beta 1 are ready for review here : http://nant.sourceforge.net/releasenotes.html (and in cvs ofcourse). With respect to the latest item: Automatic quoting of arguments (built-in type) has been removed for non-file arguments (arg value=...). This breaks build files that assume that argument values containing spaces will be quoted. I was confused when this was first announced in the last few days, but didn't have time to comment then. If the reader isn't particularly familiar with the exec task, then the arg type may be unfamiliar as well. My initial reading was that this was talking about arguments to built-in functions, and the example was simply poor. It also assumes that the reader was aware that automatic quoting was taking place, a point that's not mentioned in the arg documentation. Finally, there's confusion as to when the quoting is taking place - as part of the parsing of the build file (which really confused me, as I always thought XML required quotes on all attribute values) or when passed to the exec task - especially before I realized that arg was used by exec. For this item, I suggest: Previously, the arg type (used by the exec task) would automatically add quotes to both file= and value= attributes, so that they'd be quoted in the command line generated by the task. That automatic quoting has been removed for value= attributes (but not for file= attributes), because In general, with release notes about behavior changes, I always found that general style (Previously ... Now), although wordy, saves me the trouble of having to look up things in the manual just to understand the release note and figure out whether or not I cared. Gary PS: Part of the problem is just the terminology. NAnt uses type in two ways, one for the types of items within expressions, and one to certain constructs that can be used as task elements. I've never been fond of the latter use, mostly because it's not introduced well in the documentation, but also because extrapolating the use of the word type from conventional programming languages to NAnt syntax is unfamiliar and feels unnatural --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Access to TaskBuilder
Why has TaskBuilder become internal? I need to be able to manipulate task definitions and can no longer do this. If I want to replace the task which is defined under the taskname csc - how can I do that? Our current code is this: TaskBuilder currentCSC = TypeFactory.TaskBuilders[csc]; TaskBuilder newCSC = new TaskBuilder(Clover.Nant.CloverCSCTask, Assembly.GetExecutingAssembly().Location); TypeFactory.TaskBuilders.Remove(cscBuilder); TypeFactory.TaskBuilders.Add(newCSC); The latest NAnt code in CVS has broken this. Conor (Sorry if this is a dupe - first attempt is in moderation) --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Re: [Nant-users] NAnt 0.85 release notes + to-do's
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Tuesday, 3 August 2004 9:46 PM To: Gary Feldman; Nant-Developers (E-Mail) Subject: [nant-dev] Re: [Nant-users] NAnt 0.85 release notes + to-do's Hi Gary, Thanks for the feedback. I've updated the description of this breaking change as follows : In previous versions of NAnt, the arg element (used by, for example, the exec task) would automatically add quotes for both file and value attributes in the command line generated by the task. That automatic quoting has been removed for value attributes (but not for file attributes). This change may break build files that assume that both arguments specified using the file and value attributes will automatically be quoted. Is this ok for you ? Gert FWIW, I think Gary's wording is better than mine :-) More verbose isn't bad, while more explicit is very good. I guess my reasons for talking about the Argument element type rather than the arg element is that a task is free to change the element name while using the same element type. With some thought however, this is not likely to happen, and the great majority of people probably don't care :-) -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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
The ability to better-control the output of the exec task seems to be a common feature query... I'm looking at putting together a patch for this, but would like to solicit comment on my proposed solution: Create an element type ExternalProgramOutput with three attributes - file (FileInfo), property (string) and log (bool). ExternalProgramBase will include two extra (non-attributed) public properties - stdout and stderr, both of type ExternalProgramOutput. For each of stdout and stderr, if the file attribute is specified then output will be logged to the specified file; if the property attribute is specified, then the output will be stored in the specified property; if log is true then output will be logged as normal, if false then output will be suppressed from the build log. Each of these attributes is orthogonal. If the stdout and stderr elements both specify the same file to log to, then output is (safely) interleaved into the log file - so the file contents will be essentially identical to running the command on the console and redirecting both stdout and stderr to a file, the only major difference being that stderr will not break into any stdout output. If either the stdout or stderr element is omitted, it will behave exactly as if the element were included with null attributes. That is, output will be included in the build log but not redirected or stored in a property. ExternalProgramBase's output attribute will be deprecated but still work as-is. Examples: exec program=foo.exe stdout file=out.txt / stderr file=out.txt / /exec * Exactly the same behaviour as the current exec program=foo.exe output=out.txt / exec program=foo.exe stdout file=out.txt / stderr file=err.txt / /exec * Redirect standard output and standard error to different files. exec program=foo.exe stdout property=foo log=false / /exec * Silently store the output of the program in the property 'foo'. Any errors will still appear in the build log. I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. Comment By: Gert Driesen (drieseng) Date: 2004-08-02 19:09 Message: Logged In: YES user_id=707851 I guess we should actually allow separate files for standard and error output. Please submit a feature request or a patch for this. I'm closing this bug now as I'm not able to reproduce this issue. 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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAnt 0.85 release notes + to-do's
-Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 August 2004 3:13 AM To: Troy Laurin; Nant-Developers (E-Mail) Subject: Re: [nant-dev] NAnt 0.85 release notes + to-do's Troy, I committed some changes to the release notes (and index.html). I'll upload a new nightly build soon. The changes look good. Apologies for the incremental changes, but there are a couple more: General changes: * This release of NAnt introduces support for expressions. should probably be * Added support for expressions. for better consistency with other general changes Commandline changes: * Deprecated -[defaultframewor]k option in favor of -[t]argetframework. should be * Deprecated -[defaultframewor]k option in favor of -t[argetframework]. * Added -emacs option could be * Added -e[macs] option Actually, regarding these last two, * The default logger will now also output the number non-fatal errors and warnings. this should probably be in general changes Finally, will the title for the 0.85-beta 1 release become 0.85-rc1 (or 0.85-rc 1), to be consistent with previous releases? I wonder if we should also use links for all the task/types headers (eg. csc) ? Not sure I like the layout that much when we change the headers into anchors/links. Previous releases in the file don't (hardly) include links at all... Adding links to the task/type headers doesn't affect the layout, does it? If it's a stylistic thing, then you could suppress the link underline and colour through the style sheet... Certainly, the file would become rather busy if each of these headings was underlined in blue. -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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
Troy Laurin wrote: I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. you could write a small c# commandline app that writes to stderr and use that to call from exec. Why not just post the test code when you have it and those of us running non-win32 platforms can test it there. Ian Comment By: Gert Driesen (drieseng) Date: 2004-08-02 19:09 Message: Logged In: YES user_id=707851 I guess we should actually allow separate files for standard and error output. Please submit a feature request or a patch for this. I'm closing this bug now as I'm not able to reproduce this issue. 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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
-Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 August 2004 11:54 AM To: Troy Laurin Cc: Nant-Developers (E-Mail) Subject: Re: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec Troy Laurin wrote: I'm not confident writing tests for this for any platform other than Win32, however - basically I don't know what standard commands might be available that emit a known text to stderr, and don't have access to a machine to run the tests. you could write a small c# commandline app that writes to stderr and use that to call from exec. Why not just post the test code when you have it and those of us running non-win32 platforms can test it there. Ian Ideally I want an application that is guaranteed to be available that has stable output, so a stable test could be added to the ExecTaskTest fixture. I guess the most robust/generic way to do this would be to use a small purpose-build C# application as you suggest, but is there a way to ensure this application would be generated prior to running these tests, and cleaned up afterwards? -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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Extend CustomXmlProcessing to attributes
It would be good to extend the recent introduction of
CustomXmlProcessing in Element.cs to attributes, so a Task can take over
all XML processing, not just child elements. This would require changing
if (UnprocessedAttributes.Count 0) {
to
if (!Element.CustomXmlProcessing UnprocessedAttributes.Count 0) {
Cheers
Conor
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [ nant-Bugs-968278 ] Output redirection of exec
Troy Laurin wrote: you could write a small c# commandline app that writes to stderr and use that to call from exec. Why not just post the test code when you have it and those of us running non-win32 platforms can test it there. Ian Ideally I want an application that is guaranteed to be available that has stable output, so a stable test could be added to the ExecTaskTest fixture. I guess the most robust/generic way to do this would be to use a small purpose-build C# application as you suggest, but is there a way to ensure this application would be generated prior to running these tests, and cleaned up afterwards? either; - build it during the regular nant build process and just call it form the test or - build it during the 'setup' phase of the test and delete it during 'teardown' Ian --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
