[nant-dev] [ nant-Bugs-1073214 ] command line property
Bugs item #1073214, was opened at 2004-11-25 15:47
Message generated for change (Settings changed) made by drieseng
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
Category: Core
Group: cvs
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: john roland (jroland)
Assigned to: Gert Driesen (drieseng)
Summary: command line property
Initial Comment:
Hi
I've got a warning message each time i try to set a
property with the -D swith.
here is a sample.
name file:
http://nant.sf.net/schemas/nant-
0.85.win32.net-1.0.xsd" default="go">
command line:
nant -D:name="John smith"
message:
[property] Read-only property "{0}" cannot be
overwritten.
It seems like the command line parser is creating an
empty parameter for each parameter.
keep it up !!!
thank you
John Roland
--
Comment By: Gert Driesen (drieseng)
Date: 2004-11-25 17:44
Message:
Logged In: YES
user_id=707851
The error message was incomplete. This was fixed since.
However, the behavior is correct. Each property that is set
on the command line is read-only by design.
You can avoid that warning from being output in the build log
by using :
This will only try to set that property if it hasn't been set
before.
Hope this helps !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1073214 ] command line property
Bugs item #1073214, was opened at 2004-11-25 15:47
Message generated for change (Comment added) made by drieseng
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
Category: Core
>Group: cvs
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: john roland (jroland)
>Assigned to: Gert Driesen (drieseng)
Summary: command line property
Initial Comment:
Hi
I've got a warning message each time i try to set a
property with the -D swith.
here is a sample.
name file:
http://nant.sf.net/schemas/nant-
0.85.win32.net-1.0.xsd" default="go">
command line:
nant -D:name="John smith"
message:
[property] Read-only property "{0}" cannot be
overwritten.
It seems like the command line parser is creating an
empty parameter for each parameter.
keep it up !!!
thank you
John Roland
--
>Comment By: Gert Driesen (drieseng)
Date: 2004-11-25 17:44
Message:
Logged In: YES
user_id=707851
The error message was incomplete. This was fixed since.
However, the behavior is correct. Each property that is set
on the command line is read-only by design.
You can avoid that warning from being output in the build log
by using :
This will only try to set that property if it hasn't been set
before.
Hope this helps !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Fileset / task change
Gert Driesen wrote: If I'm not mistaken, Ant only outputs a verbose-level message to the build log when a file, that is specified using the "file" attribute, does not exist. When a directory that is specified using the "dir" attribute does not exist, no message whatsoever is output to the build log. What the "quiet" attribute seems to do is (correct me if I'm wrong) : - no longer have the task fail when a file/directory that is matched by a fileset cannot be deleted (not just when it doesn't exist) - output the cause of a failure using a verbose-level message instead of using a warning level I'd have to look at the source to confirm this... I'm not running Ant in verbose mode, and I'm only deleting files :-P It wouldn't surprise me if you're right, though. What we should do is : - only output a verbose-level message when the file / directory pointed to by the "file" or "dir" attribute does not exist. Never fail the task if a file or directory specified using the "file"/"dir" attribute does not exist. This would match the behavior of Ant, except for the fact that Ant does not output any message when the directory pointed to by the "dir" attribute does not exist. This can be changed for the 0.85 release, and documented as a breaking change. Sounds good, except for the never failing... I'd still lean towards failing if the file/directory doesn't exist, because it will catch typos that otherwise might be difficult to track down. Perhaps an attribute 'failonnomatches' (fail on no matches... there has to be a more readable name?!) which would suppress the failure with no warning if the file doesn't exist, but fail if the file exists but can't be deleted - as opposed to 'failonerror' which would print a warning if the file doesn't exist. Or am I being too fail-safe paranoid? - add support for either a threshold or loglevel attribute to tasks (or both) after the 0.85 release. This will allow build authors to control build output on a task-level in a generic way, instead of introducing such a mechanism for specific tasks. I would suggest that it would be more useful (in general) to specify logging levels declaratively... that is, to specify an xml file (for example) which defines the thresholds and/or loglevels for each task; this could also be set through a task, then the configuration mechanism could be an included build file. Then again, I can see the point of task instance level log filtering, if you want to suppress logging for just a single task, but not for other instances of the same task in the build... would it be excessive to include both? -- Troy --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1073214 ] command line property
Bugs item #1073214, was opened at 2004-11-25 15:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: john roland (jroland)
Assigned to: Nobody/Anonymous (nobody)
Summary: command line property
Initial Comment:
Hi
I've got a warning message each time i try to set a
property with the -D swith.
here is a sample.
name file:
http://nant.sf.net/schemas/nant-
0.85.win32.net-1.0.xsd" default="go">
command line:
nant -D:name="John smith"
message:
[property] Read-only property "{0}" cannot be
overwritten.
It seems like the command line parser is creating an
empty parameter for each parameter.
keep it up !!!
thank you
John Roland
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1073214&group_id=31650
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Re: Fileset / task change
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Troy Laurin > Sent: donderdag 25 november 2004 14:20 > To: Martin Aliger > Cc: [EMAIL PROTECTED] > Subject: Re: [nant-dev] Re: Fileset / task change > > Martin Aliger wrote: > > > If this change is done, what about to lower verbosity when deleting > > non-existing files/folders also? I think verbose level is > ok for that > > (todays it is error via BuildException). > > > > Martin Aliger > > > > Ant deals with this with a quiet="true": > > quietIf the specified file or directory does not exist, do not > display a diagnostic message (unless Ant has been invoked with the > -verbose or -debug switches) or modify the exit status to reflect an > error. When set to "true", if a file or directory cannot be > deleted, no > error is reported. This setting emulates the -f option to the Unix rm > command. Default is "false". Setting this to "true" implies setting > failonerror to "false". > > > This seems to work well, because sometimes if the > file/directory you are > trying to delete doesn't exist it flags an error... typo in > the build file? If I'm not mistaken, Ant only outputs a verbose-level message to the build log when a file, that is specified using the "file" attribute, does not exist. When a directory that is specified using the "dir" attribute does not exist, no message whatsoever is output to the build log. What the "quiet" attribute seems to do is (correct me if I'm wrong) : - no longer have the task fail when a file/directory that is matched by a fileset cannot be deleted (not just when it doesn't exist) - output the cause of a failure using a verbose-level message instead of using a warning level What we should do is : - only output a verbose-level message when the file / directory pointed to by the "file" or "dir" attribute does not exist. Never fail the task if a file or directory specified using the "file"/"dir" attribute does not exist. This would match the behavior of Ant, except for the fact that Ant does not output any message when the directory pointed to by the "dir" attribute does not exist. This can be changed for the 0.85 release, and documented as a breaking change. - add support for either a threshold or loglevel attribute to tasks (or both) after the 0.85 release. This will allow build authors to control build output on a task-level in a generic way, instead of introducing such a mechanism for specific tasks. Gert --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Fileset / task change
Martin Aliger wrote: If this change is done, what about to lower verbosity when deleting non-existing files/folders also? I think verbose level is ok for that (todays it is error via BuildException). Martin Aliger Ant deals with this with a quiet="true": quietIf the specified file or directory does not exist, do not display a diagnostic message (unless Ant has been invoked with the -verbose or -debug switches) or modify the exit status to reflect an error. When set to "true", if a file or directory cannot be deleted, no error is reported. This setting emulates the -f option to the Unix rm command. Default is "false". Setting this to "true" implies setting failonerror to "false". This seems to work well, because sometimes if the file/directory you are trying to delete doesn't exist it flags an error... typo in the build file? While the task is being changed anyway :-) -- Troy --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Suggestion for call element
Bruce Leggett wrote: It would be nice if call target could accept parameters. Also if you could specify a file the target is located in then there would be increased encapsulation. Then code would be easier to maintain. Also if the target could return a value. If there is something like this already then let me know. Example: ... BuildTarget.build file contents: I haven't gave this much thought but I think you will get the idea. Maybe make a function target? Anyways I just want to get somebodies wheels turning. Thanks, Bruce Leggett Software Engineer Advanced Systems Technology, Inc. 850.475.4006 This has been discussed previously, and I personally like the idea. It was (rightly) looked at as something that should be fully explored and done properly if/when it's done... but I forget where the discussion was left. As a comment on the above, I'd suggest being able to specify parameters as read/write so the calling target will be able to pick up any changes made to the parameter by the called target, instead of using returns: No good! [...] Regards, -- Troy PS- If your target is in another build file, then the task can be used, which already supports calling a target with extra properties! --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
