Troy Laurin wrote:
Ian MacLean wrote:No quite silently - a message was added to the log - but I take your point. The problem as I see it is that this:
Merrill Cornish wrote:
it appearedFelice,
In the new, improved NAnt, properties now have the option of a readonly attirbute. Furthermore, any property set because
in a -D:property=value item on the script command line will automatically be readonly. So, you can't change in the script the value of a property passed in via the command line.really ? When did that change come in ?
It's in the release notes-in-progress (0.85), General changes... * Overwriting of read-only properties will now result in a build failure.
It doesn't seem right that you can't set a default in the build file and have it overwritten by the value passed on the commandline. This is a fairly common use case. The previous behaviour probably makes more sense.
If it's a common use case, then perhaps it should be moved into the Breaking changes section of the release notes?
The previous behaviour of silently ignoring the property task if the
property is read-only certainly isn't optimal, either. Silently
ignoring tasks can make some bugs hard to trace.
<property name="foo" value="bar" readonly="true" /> <property name="foo" value="baz" />
isn't the same as:
<property name="foo" value="bar" />
nant -D:foo=baz
at least not to most users. Conceptually it looks like the commandline value is overriding the script value rather than the other way round ie the commndline value comes first.
in the first case throwing an exception is the right thing to do and the resulting error message relates well to the build file contents. In the 2nd the error doesn't quite make sense - unless you happen to know that commandline properties are read only. A users first thought will be to look in the build file and say "hey but that property isn't set to readonly'. I would lean towards having the propertly task silently ignore if the property had been set from the commandline.
Maybe we should treat properties passed on the commandline differently from readonly properties defined in the build file.
sure but you'll need to add the unless attribute for *every* property that a user might choose to set from the commandline.A change to the property statement to remove the breakage: <property name="junk" value="Development 1.4" unless="${property::exists('junk')}" />
The above has the addition of being somewhat self-documenting as a default, in addition to not overwriting non-readonly values of the property set in other locations in the build file.
Maybe they shouldn't be read-only - perhaps they should just override the same property name set at the project level and then be re-writable later on. Just thinking out loud now.With regards to properties set on the commandline being read-only, it has always been a slight concern to me that you could break a build by specifying a property that's used internally (and expected to be non-readonly) on the commandline. I don't know of a good solution to this, though.
Ian
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
