Gary Feldman wrote:
> >From: "Ian MacLean" <[EMAIL PROTECTED]>
> >Sent: Thursday, August 12, 2004 6:40 AM
> >
> > Actually I don't see how adding property files is any
> > different from
> > using the <include> task to import properties. And I don't
> > see how it
>
> There are a number of ways that the property mechanism in Ant
> is different from NAnt.
>
> The most obvious is that the property file syntax is much
> simpler. This may not seem like much, but not only does it
> make it easier to read the property file, it also guarantees
> that the property file isn't doing anything funky behind your back.
The side-effectless nature of Ant's property files is a good point, but
it's very simple to write a foreach loop in NAnt that will parse an Ant
property file (in a somewhat naive fashion):
<foreach item="Line" property="prop.name,prop.value" delim="="
in="${properties.file}">
<do>
<property name="${prop.name}" value="${prop.value}"
unless="${string::starts-with(prop.name, '#')}" />
</do>
</foreach>
Granted, the above doesn't deal with properties containing other
properties (bar=hello; foo=${bar} world), but this could be addressed
with the addition of a function 'expression::evaluate(string)'.
Simpler syntax is a double-edged sword, too... another way to say that
the property file is simple is to say that it is not very
self-descriptive.
Say you make a typo in your property file, and hit = instead of -...
property=name=foo
This will parse correctly, and give you a property named 'property' with
a value of 'name=foo'. The same typo in a property task will correctly
cause an error because a property name cannot contain '='. If using the
property file, the build script will perform incorrectly, and the
resulting errors may be difficult to diagnose.
Also, particularly in NAnt, the property task does more than just set
the value of a property. If using a simple property file syntax,
there's no way to specify whether a particular property's value is
dynamic, or if it should overwrite an already-set value, or if the new
value should be considered read-only. Ant gets around these problems by
enforcing answers to all of these questions.
> More functionally, in NAnt, include files can only be
> included at the top level. This means you can't have a
> target decided which of several property files to load.
> There are probably ways to work around this in NAnt, but
> that's just another complexity.
That's certainly true.
One (possible) way to address this is an RFE to allow child build files
(called with the nant task) to set properties in the calling build file.
<nant buildfile="${properties.buildfile}" share-properties="true" />
This would have the side-effect that any properties that are set in the
child buildfile will be visible from the calling build file after the
nant task has completed... NAnt property files could then be executed
using the nant task rather than the include task, and so becomes valid
in a target.
There may be better ways.
> Related to property files, there are property sets. This
> makes it easier to treat properties as a group. The
> combination of property sets and property files makes it easy
> to pass different sets of properties to subtasks.
While this is an interesting idea, I can't think of any practical uses
for this. Are there any examples of cases where this simplifies things?
> Also, in Ant properties are always immutable (i.e. readonly).
> The evaluation order is well defined and the confusion over
> the property's value at any given time is reduced..
Personally, Ant's immutable properties were the bane of my build
scripts. Practically, it often meant creating stupidly-named temporary
mid-evaluation properties just to get the final value in a meaningful
property. Well, stupidly named was probably my fault, but the actual
problem was the polluting of the namespace with temporary properties
that shouldn't exist after the evaluation was complete.
No other language I have worked with (or know of) has the concept that
you can never change the value of a property after it's been set.
> The way this affects the issue of properties on the command
> line is to encourage a simple consistent architecture.
> Instead of providing a number of properties on the command
> line, or having to remember the exact names and values for
> them, all the user really needs to do is to remember a set of
> file or directory names. This could be done in simple NAnt
> files using <include>, but as pointed out above, that's not
> as flexible. Either way, by relying heavily on property
> files, command line typos are found earlier (i.e. when the
> attempt to load the property file fails, rather than when a
> specific property is used).
I think it's potentially very misleading to have a build script driven
by properties in a file external to the script itself. If a property
has an intelligent default, then it should be defined with that default
in the build script. If it doesn't have an intelligent default, but has
a constant value in a particular context, then the common solution would
be to have a bootstrap file (batch file, shell script or build script,
pick your poison) that sets the properties to their required values
before starting the build proper. Introducing property files into this
tends to divorce the properties from their context (at least in my
experience), so it's not quite as obvious as it could be where to start
looking if an error occurs.
Your mileage may vary.
What's really interesting to me in this discussion is that I come from
an Ant background myself, and I was aghast at the lack of (in-built)
support for property files. I've since decided to try things the NAnt
way, keeping properties tightly bound to their context, and the result
is that (IMHO) the actual build script is clearer on inspection than if
the property is defined elsewhere.
-- 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
