> I understand your frustration but I disagree with what you said.... I > created many of the tweaks that make the Cocoon build.xml file hard to > understand.... and I know that. But, man, this was driven by need and > nobody was here to propose anything better so I coded it... since the > addiction s were quite general and useful, I thought others could > benefit from it.
Yeah, I know.. If you need it make it, and then figure it out later. I understand that this is the way the world works. And instead of whining about it, I'm working on some stuff, a design doc first of all. > also, I'm scared to death about placing scripting inside ant... but Sam > made it a task, so the core simplicity is preserved. You can build your > own simple ant build files and let others do the complex things, if they > care. By making it a task, I'm cool with scripting. Now, obviously, if you have scripting, you need to have a good model of the overall internals of the project exposed to that scripting... But I leave that part in Sam's capable hands. As long as you see the object tree of project/target/task then I'm happy. > Also, the need for elements inside task-elements is _very_ needed... > this is something I totally agree with and make Ant much more portable > and easier to "GUI-fy" (the Forte module is pretty cool even if throws > NPE on the cocoon build.xml) Yep. We need to have a good answer for how things underneath the project/target/task hiearchy are represented in the XML. .duncan
