Jose Alberto Fernandez wrote: >... > should > we see <include> as loading some structures piece of XML something like > a <projectmodule/> entity. In other words have some well defined concept > of what is being included, with well defined visibility and name space > rules.
That reminds me of a possible feature, maybe "cascading build files," I was just thinking about yesterday. I have a system broken down into a couple of modules, with a top-level build file and a build file in each module directory. I'd like targets from the top-level build file to be visible when I'm in a module directory or subdirectory and do "ant -find ... sysTarget". Currently, to implement that, for each target T in the top-level build file, in each module build file I define an identically named target that delegates up to the parent build file (using <ant dir=".." .../>). It might be nice if there were a way to look for a target in more than just the first build file encountered in the -find traversal up the hierarchy. (Obviously, one problem would be defining how far up it searches. Maybe something marks the system boundary and searching terminates there if the target isn't found.) Giving multiple targets to Ant would cause definitional problems if Ant actually searched up the hierarchy. (How would "ant ... A X B work if A and B were in one file and X were in a different one?) Maybe a better way would be to have targets in the top-level build file be visible in the module build file (almost as if the module build file were a subclass of the module build file, or like cascading style sheets). This could be enabled by some explicit construct (some type of include command) so avoid problems with implicit inclusion. Obviously, this idea is going to sound weird, but does anything think it or parts of it would be useful? Is this something that would be covered by whatever kind of templating is being considered? Daniel -- Daniel Barclay Digital Focus [EMAIL PROTECTED]
