The problem is that you use the "genericantfile" attribute. This implies the current (master) script into the projects. Therefore you'll get a cycle between <subant> and <import>.
Jan > -----Ursprüngliche Nachricht----- > Von: Francisco Tolmasky [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 29. November 2007 13:43 > An: [email protected] > Betreff: Alternative to subant > > My project currently uses a common build file to build a > number of sub- > projects > (each of which may also have a sub-project as well). My first > inclination was thus > to use the subant task to build all these subprojects, as so (almost > straight out of > and subtask documentation): > > <macrodef name = "iterate"> > > <attribute name = "target"/> > > <sequential> > <subant inheritall="false" inheritrefs="false" target = > "@{target}" genericantfile = "build.xml"> > <dirset dir = "." includes = "*.subproj"/> > </subant> > </sequential> > > </macrodef> > > <target name = "Build-Project"> > > <!-- Do Stuff --> > > <iterate target = "Build-Project" /> > </target> > > However, this fails with "subant task calling its own parent > target." > This shouldn't be happening > because I am calling the target on a different directory. I snooped > around the web and enough > people have run into this for me to consider it a bug and > thus a lost > cause. My question instead > is how to alternatively achieve this same effect. I tried using > <apply executable = "ant"> to > achieve something similar to this, but with little luck. Any > thoughts > or suggestions? > > Thanks, > > Francisco Tolmasky > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
