Ian Maclean wrote:
> >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.
> >
> >
> No quite silently - a message was added to the log - but I
> take your point. The problem as I see it is that this:
>
>
> <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.
That's probably the best description of the problem that I've seen. I
agree with your interpretation, that conceptually the commandline
property is the overriding property.
> 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.
If you treat commandline properties differently to those defined in the
build file, then will you treat properties specified in the <nant>
element in the same way - so you can use one NAnt script to bootstrap
another. What about inherited properties?
To offer my own suggested answer to the above...
I think that explicitly passed properties in the nant task should behave
the same way as commandline-defined properties (read: identically,
IMHO... but what happens if one of these properties overlaps with a
commandline argument? More thought required), for the bootstrapping
case. It _should_ be okay for inherited properties (readonly and
writable) to act as if they were defined locally in the child build
script... because if any properties are defined in the parent build
script, then it's a bit more than a simple bootstrap, so any interaction
between the two files are 'to be expected', by the definition of
inherited properties. Caveat emptor, as they say. Unless they're
better at latin than I am, and know how to say "user beware" instead of
"buyer beware" :-)
> >A change to the property statement to remove the breakage:
> ><property name="junk" value="Development 1.4"
> >unless="${property::exists('junk')}" />
> >
> sure but you'll need to add the unless attribute for *every* property
> that a user might choose to set from the commandline.
True. Actually, I'm protecting against this in the opposite direction
in one of my utility build files:
<fail if="${property::exists('view.path') and
property::is-readonly('view.path')}">
clearcase.export.* cannot be used if 'view.path' is set
read-only.
</fail>
The 'view.path' property is used internally to specify where the
temporary view is created... at the end of the export operation, this
entire directory tree is deleted. I don't want this property being set
to something readonly causing the build script (And this appears in a
utility build file, so it could be included in anything, two years from
now!) from accidentally deleting some critical part of the system.
That's a definite advantage languages with scoped variables have.
> >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.
> >
> 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.
My only real objection to this is it promotes global definition of
variables. Some programming practices promote late
definition/initialisation of variables - because the context in which
the variable is initialised will give a clue as to how it will be used.
For example, in the part of the script which sends an email, I'm setting
the default recipient address inside the mail target, just before the
mail is sent.
Perhaps a solution might be to make commandline properties writable, and
adding a function to get the value of a property as set on the
commandline (nant::get-commandline-property('foo'))? I imagine this
would break more than a few build scripts.
To help (??) avoid potential read-only/writable property conflicts, a
soft naming convention could be instituted in which a warning is emitted
if the name of a read-only property isn't in all uppercase, or if the
name of a writable property is. Then you could look at a build script
and easily tell if a property is likely to be writable. Or is this
overly legislative?
Ant really took the easy way out, making all properties (frustratingly)
read-only.
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.
-------------------------------------------------------
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
