For something related to what you do in parent.xml, the post below uses Javascript to call all the subprojects. Note how it sets dir attribute of <ant>... You may want to do the same in your parent.xml. --DD
-----Original Message----- From: Steve Allan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 28, 2002 7:19 PM To: 'Ant Users List' Subject: RE: Passing targets to subprojects with ant using javascript After reading the antlist archive a little better, I found a thread from January that matched my situation in which Peter showed a way which is much better. Turns out I was trying to do it backwards. Instead of having my subproj script be a dependency for my targets, it's much more natural to have the targets call the script. As Peter suggested: <target name = "clean"> <antcall target = "call"> <param name = "script.target" value = "clean"/> </antcall> </target> Then all references in the javascript are to "call", instead of the target I'm trying to pass. Don't know what the heck I was thinking before! My modified example is included below just to complete the thread - critique is always welcome. Thanks. -- Steve <!-- clean target --> <target name = "clean"> <antcall target = "dosubproj"> <param name = "target" value = "clean"/> </antcall> </target> <!-- dosubproj target calls ant in each subproject and passes target --> <target name="dosubproj"> <script language="javascript"><![CDATA[ // Add new subprojects to this array. They'll be built // in the order they appear in the array. var subproj = new Array( list snipped to save space ); for (i = 0; i < subproj.length; i++) { target = new java.io.File(testproj.getProperty("target")); build = testproj.createTask('ant'); build.setAntfile("build.xml"); build.setDir(new java.io.File(testproj.getProperty("basedir") + "/" + subproj[i])); build.setInheritAll(false); // Pass the target name unless it's the default target if(target != "") { build.setTarget(target); } dosubproj.addTask(build); }]]> </script></target> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Chad Loder [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 10:55 PM To: Ant Developers List Subject: Re: Ant <project> extension, templatized build files Peter wrote: > I would recomend you have a look at the existing projects as they are more > likely to be imediately usable by you. I am personally turned off by what I've seen of Maven and (to a lesser extent) Centipide. Ant is attractive because it aims only to be a great, NEUTRAL build tool. Using ant by itself implies no particular project management/structuring ideology (i.e. "eXtreme programming", "The Apache way (tm)" or whatever the buzzword of the year is). I don't want anyone telling me how to structure my projects, how to do my unit testing, etc. Rather than using Maven and struggling to turn all the unwanted stuff off, I would like to use ant and build what's necessary from scratch. To sum it up, I don't think one needs all the Maven baggage to implement templatized buildfiles. Kudos to the Maven people and all...it's just not how I do things. Therefore let me re-state my problem in the simplest way I can. "Given a set of subprojects whose buildfiles share a high degree of redundancy, how do I reduce this redundancy by factoring the redundant portions into a single buildfile, while retaining the flexibility to override the definitions of particular targets." Having thus restated my problem, I sat down and played with ant 1.4, coming up with a solution that does what I need, without requiring any ant changes whatsoever. I describe my solution below -- I'd like to know what people think of it. Peter, in particular, I think you and I may be trying to solve different problems (my needs being somewhat simpler). I'd like to get comments on this proposed solution (improvements? possible complications or limitations down the road for large projects?). THE SOLUTION ------------ Assume there is one main project "parent" which consists of two similar "Sibling"-style subprojects, "brother" and "sister". The steps required to build a Sibling are always the same, subject to minor differences subproject-specific differences (compile flags, pre-build and post-build steps, etc.). If one had other kinds of subprojects (e.g., in addition to Siblings, one wanted to build WinExe's or WinDLLs, etc.), one could make a template-winexe.xml, template-windll.xml, and so on. I created 4 build files: build.xml: the parent build file brother.xml: the build file for the "brother" subproject sister.xml: the build file for the "sister" subproject template-sibling.xml: the "Sibling" template [...] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
