I don't disagree with you. I just think that given the state of the Ant code base, what you want to do is difficult, and would require major refactorings you would be likely enable to get past the committer. So my advise would be to stick with Ant-contrib's <foreach> calling another target, and live with the expense of the implicit <antcall>... --DD
-----Original Message----- From: Brian Pontarelli [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 12:11 PM To: Ant Users List Subject: RE: TaskContainer and setProperty <snip> Can you explain what you're doing that would require this modified <foreach>? --DD </snip> Well, I'm not really doing anything special except that flexibility is nice. To be able to place the tasks inside the foreach rather than in a new target keeps the build file cleaner. The ant API seems to be lacking in these respects. Think how easy it would be for the foreach tag to be written and how much faster it would be if you could simply use project.executeTarget() rather than having to basically re-execute ant with the same build file calling the specific target (which is basically what the antcall does because it uses the ant task). Also, there doesn't seem to be a robust way to managing properties scopes. For example: <someTask1> <someTask1.1> <someTask1.1.1/> </someTask1.1> <someTask1.2> <someTask1.2.1/> </someTask1.2> </someTask> If someTask1 sets a property, then someTask1.* should see it. However, if someTask1.1 sets a property someTask1.2 should not see it, unless it is marked parent visible or something. This is a fundamental programming language concept and that's basically what ant is, a scripting language of sorts. Anyways, that seems to be something that ant2 should really consider because it would make like much easier for developers. Brian -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
