Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 9658 invoked from network); 5 Sep 2002 17:46:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Sep 2002 17:46:03 -0000 Received: (qmail 27162 invoked by uid 97); 5 Sep 2002 17:46:14 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 27123 invoked by uid 97); 5 Sep 2002 17:46:13 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 27102 invoked by uid 98); 5 Sep 2002 17:46:13 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <5164A49467308C45AD50661F8CFDC34302B5029B@s30342g004004> From: "Vaughn, Julia" To: "'Ant Users List'" Subject: RE: & (was 'RE: Automated source config model?') Date: Thu, 5 Sep 2002 13:45:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Where is 'foreach' documented? -----Original Message----- From: Dominique Devienne [mailto:DDevienne@lgc.com] Sent: Thursday, September 05, 2002 12:54 PM To: 'Ant Users List' Subject: RE: & (was 'RE: Automated source config model?') Two remarks: 1) Normally (used internally by ) passes properties to the called project automatically, but since it appears it's not in your case, try passing it explicitly. I discovered (yesterday actually!) that supports nested , as does, although it's not documented. So try: I assume you made sure comptag was property set by in 'checkout-dirs'. 2) 'checkout-dir-notag' might never be called, since might define the comptag property anyhow, even if ${component}.tag doesn't exists??? Personnaly, since you're already using ant-contrib, I would simple have done: Hope this helps. --DD -----Original Message----- From: Matt Lyon [mailto:matt@stargus.com] Sent: Thursday, September 05, 2002 11:22 AM To: Ant Users List Subject: & (was 'RE: Automated source config model?') DD, Thanks for the information! The issue I was facing seemed to be due to property scope/flow control. I had placed a task to read in properties from an external properties file inside an init target, which did not allow the subsequent targets to work the magic of expanding nested properties in that same property file which you so eloquently described. If I place the at the level in my buildfile and not inside any target, that gets me past the problem. However, I'm still stuck on a issue. Using Matt McHenry's model again, if I have an external properties file that lists the following: #The list of modules components=platform,ui,content #The tag for the 'platform' module platform.tag=V1_0_6_183 #The platform directories platform.dirs=starman/src/com/stargus/platform #The tag for the 'ui' module ui.tag=V1_0_6_183 #The ui directories ui.dirs=starman/src/com/stargus/web,starman/src/web #The tag for the 'content' module content.tag=V1_0_7_184 #The content directories content.dirs=starman/src/com/stargus/platform/content And a build.xml which contains the following target sequence: What I'm finding is that the ${complist} property value is passed to the checkout-dir tag as param ${ckout.pkg} with the expected iterations performed, but the checkout-dir-tag target is never executed because the ${comptag} property value is either not getting defined by or is not recognized by the checkout-dir composite target due to some sort of flow control or property scope issue. How can I force the setting and propagation of the ${comptag} property value to the subsequent targets? Matt -----Original Message----- From: Dominique Devienne [mailto:DDevienne@lgc.com] Sent: Wednesday, September 04, 2002 5:43 PM To: 'Ant Users List' Subject: RE: Automated source config model? The sets the 'component' param (not property, but the distinction is small), passed to the 'checkout-dirs' target. This target in turn doesn't use the 'component.dirs' property, it uses the 'component' property, to lookup the '${component}.dirs' property, where ${component} is resolved to its value (for example, acme.dirs). This is the bit of magic does, allowing nested properties (it's equivalent to the illegal ${${component}.dirs}). I don't thing this has anything to do with property immutability. Hope this helps. --DD -----Original Message----- From: Matt Lyon [mailto:matt@stargus.com] Sent: Wednesday, September 04, 2002 4:19 PM To: Ant-User (E-mail) Subject: RE: Automated source config model? Matt, Thanks for the information. What I don't understand about your approach is how the foreach task in your checkout target can pass a param to the propertycopy task to define the value which it is supposed to then associate with the matching property value in from the propfile to create a new property. Specifically, I'm referring to ^ and ^ There's probably a really simple explanation, but I'm missing something conceptually here. If I try something similar my build bombs out because the value of ${component.dirs} is not defined for the checkout-dirs target. Is this due to property immutability holes being plugged in Ant 1.5? Matt -----Original Message----- From: McHenry, Matt [mailto:mmchenry@carnegielearning.com] Sent: Tuesday, September 03, 2002 5:07 PM To: Matt Lyon Cc: Ant Users List Subject: RE: Automated source config model? > Thanks for the information. I would be interested in seeing how you implemented what you have if > you can give me a high level view without ruffling any feathers. Thanks. Okay, here's an example java properties file that defines a set of deliverables built from several components, each checked out from CVS with a different tag. (This is a bit more than what you want, as it's geared towards checking out into a sandbox directory where the build happens, then collecting all the deliverables into a holding directory so that the installer project can find them.) #the deliverable files deliverables.files=dist/lib1.jar,dist/lib2.jar #you can also specify entire directories #deliverables.dirs #the list of components -- details of each are specified below components=platform,ui,content #the buildfile build.file=build.xml build.file.tag=BUILDFILE_03 build.dir=src build.target=jars #the tag for the 'platform' component platform.tag=PLATFORM_17 #the directories under CVS covered by that tag platform.dirs=src/platform,src/foo #the tag for the 'ui' component ui.tag=UI_08 #the directories under CVS covered by that tag ui.dirs=src/ui,src/util #leave the tag undefined to check out #to the edge of the main trunk #content.tag= content.dirs=content/site1,content/site1,content/site3 The following ant project will process this sort of properties file. You can just use the 'checkout' target to pull stuff from CVS, or if you also want to build according to the build.* properties, you can use the 'call-build' or 'copy-delivs' targets. Matt McHenry Software Developer Carnegie Learning (412)690-2442 x150 -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: