ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Liu" <k...@auctionlogic.com>
Subject RE: Why Properties became immutable
Date Fri, 21 Jul 2000 15:42:25 GMT
> -- which means that complex constructs have to be expressed *in*
> Ant, rather than
> through scripts or XSLT templates.

I totally agree - it isn't good to assume that the average Ant user
has to learn XSLT just to perform some complex tasks.  And you definitely
can't expect other users of the build file to


>
> BTW, for its own reasons, I'm still fond of the idea of scoped
> properties.  As
> well as answering the original problem in this discussion, it
> would also solve
> the problem of sub-builds changing the properties of their parent
> builds.  I
> understand the problem that properties are substituted at parse
> time.  However, I
> am all for changing this to run-time substitution.  Why?  Because
> it's *much*
> more intuitive.  It behaves like procedural code, which we all
> work with every
> day.  It's easier for beginners to learn, and easier for experts
> to work with.
> According to Stephan's description, we never need to include our
> "init" targets
> as dependencies, because they never actually "run".  Just the
> presence of the
> properties makes the rest of the file work, since they're
> substituted at parse
> time anyway.  I don't know about you guys, but this isn't at all
> intuitive to me.


Yes, the way properties behave is very unintuitive.  One would expect a
property to be available only if it was "declared" as a previous sibling
element of the current task or sibling of one of its parent nodes.


Mime
View raw message