ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <dun...@x180.com>
Subject Re: Why Properties became immutable
Date Wed, 26 Jul 2000 02:55:28 GMT
on 7/24/00 7:21 PM, Jose  Alberto Fernandez at JFernandez@viquity.com wrote:

> I think that the design of ANT was that of a declerative tool.

Speaking as the original author: Yes, it was...

The idea is "here's a list of targets, I want to execute that one (and by
the way respect the dependancy ordering)". And each target is simply a list
of tasks.

Nothing more was intended. Now, it's come a long way with the ability to
script and other things, but....

> I do not know if you can make all the parties to agree into changing
> the idea of ANT to become a procedural tool.

Procedural things go into the task code, or into scripts (which I did fight
for a while, but Sam *was* persuasive in his arguments, as well as being
correct that if you had to break away to logic, doing it in a script was a
good thing). The concept of a <foreach> task really really really makes me
queasy.

> I would agree with you on the need to have some way to encapsulate the
> scope of namedvalues (properties, variables or whatever other name).
> In particular, I am not sure with the idea of subprojects not being allowed
> to define their own local variables. This means that is is not possible
> to have two originally unrelated projects and then make one call the other
> because the property names may clash. That seems like wrong.

That does seem wrong. My posts about scoping properties to project were
stated in the single project setting, but apply almost equally to the tree'd
project setting. When a target's task starts another ant build, with a
subproject, that subproject should be "autonomous" in almost every respect
(except the ability for the parent to set props in the subproject).

.duncan


Mime
View raw message