Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 23300 invoked from network); 5 Sep 2002 16:34:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Sep 2002 16:34:40 -0000 Received: (qmail 7067 invoked by uid 97); 5 Sep 2002 16:34:46 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 7012 invoked by uid 97); 5 Sep 2002 16:34:45 -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 6993 invoked by uid 98); 5 Sep 2002 16:34:44 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: & (was 'RE: Automated source config model?') Date: Thu, 5 Sep 2002 12:22:29 -0400 Message-ID: <9093431B64301C47986EF078512912AD591326@xchange.stargus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Automated source config model? Thread-Index: AcJUWn2jxlMBCWBvSZy3WeNtbzYvRAAkOo2A From: "Matt Lyon" To: "Ant Users List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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=3Dplatform,ui,content #The tag for the 'platform' module platform.tag=3DV1_0_6_183 #The platform directories platform.dirs=3Dstarman/src/com/stargus/platform #The tag for the 'ui' module ui.tag=3DV1_0_6_183 #The ui directories ui.dirs=3Dstarman/src/com/stargus/web,starman/src/web #The tag for the 'content' module content.tag=3DV1_0_7_184 #The content directories content.dirs=3Dstarman/src/com/stargus/platform/content And a build.xml which contains the following target sequence: =20 =20 =20 =20 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]=20 Sent: Wednesday, September 04, 2002 4:19 PM To: Ant-User (E-mail) Subject: RE: Automated source config model? Matt, =20 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 =20 =20 =20 =20 =20 ^ =20 =20 =20 =20 and=20 =20 ^ =20 =20 =20 =20 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? =20 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=20 deliverables.files=3Ddist/lib1.jar,dist/lib2.jar=20 #you can also specify entire directories=20 #deliverables.dirs=20 #the list of components -- details of each are specified below=20 components=3Dplatform,ui,content=20 #the buildfile=20 build.file=3Dbuild.xml=20 build.file.tag=3DBUILDFILE_03=20 build.dir=3Dsrc=20 build.target=3Djars=20 #the tag for the 'platform' component=20 platform.tag=3DPLATFORM_17=20 #the directories under CVS covered by that tag=20 platform.dirs=3Dsrc/platform,src/foo=20 #the tag for the 'ui' component=20 ui.tag=3DUI_08=20 #the directories under CVS covered by that tag=20 ui.dirs=3Dsrc/ui,src/util=20 #leave the tag undefined to check out=20 #to the edge of the main trunk=20 #content.tag=3D=20 content.dirs=3Dcontent/site1,content/site1,content/site3=20 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. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 = =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Matt McHenry=20 Software Developer=20 Carnegie Learning=20 (412)690-2442 x150=20 -- To unsubscribe, e-mail: = For additional commands, e-mail: = -- To unsubscribe, e-mail: For additional commands, e-mail: