Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 41028 invoked from network); 27 Oct 2003 15:14:23 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 27 Oct 2003 15:14:23 -0000 Received: (qmail 45393 invoked by uid 500); 27 Oct 2003 15:14:16 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 45356 invoked by uid 500); 27 Oct 2003 15:14:16 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 45343 invoked from network); 27 Oct 2003 15:14:16 -0000 Received: from unknown (HELO ignitemedia.com) (64.157.167.108) by daedalus.apache.org with SMTP; 27 Oct 2003 15:14:16 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Tale from the front: macrodef nesting Date: Mon, 27 Oct 2003 09:15:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tale from the front: macrodef nesting thread-index: AcOcFEYBH+VnQzB+TGeD7sfOjElUOgAZ+wdAAAfjiLA= From: "Steve Cohen" To: "Ant Developers List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N You're correct about working around this problem. However, I think it's still a problem that the same ${identifier} notation can either indicate a macrodef attribute or an ant property with completely different times of resolution. In other words, the line of warning in the ant manual -- "This attribute is placed in the body of the templated task using the ant property notation - ${attribute name}. Note that is not an actual ant property" --will certainly confuse users and may therefore indicate a problem in design. -----Original Message----- From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]=20 Sent: Monday, October 27, 2003 5:37 AM To: Ant Developers List Subject: RE: Tale from the front: macrodef nesting > From: Steve Cohen [mailto:SCohen@sportvision.com] >=20 > I am now trying to experiment with some of the new features > of ant 1.6. Here's a real-world example of the difficulties=20 > of trying to replace antcalls with macrodefs. >=20 > Given the following definitions, notice that I am trying to > nest a call to the macrodef make.precompiled.web.xml inside a=20 > call to the macrodef make.se.war. >=20 > This is failing because I am trying to use the ATTRIBUTE > war.webxml inside the ELEMENT precompile which contains a=20 > call to the nested macrodef make.precompiled.web.xml. >=20 The issue is not that you are calling make.precompile.web.xml, the issue is that you are using ${war.webxml} at a point where there is no property (nor attribute) called war.webxml defined. If you look at your target make.admin.war there is no property or defined called war.webxml at that point, so you cannot just look inside the task implementation and assume that it may exist be the time is half way executing (that is too late, you need it at the point of the call to make.se.war. > I could easily fix this by substituting the actual value of=20 > the war.webxml attribute for the ${war.webxml} token. But=20 > then I lose the advantage of defining this in a single place. >=20 > Or I can create properties in the macrodef and pass them=20 > around, but that feels wrong too. =20 >=20 What you should do is define this in a property on the target and they use that property to expand the value in all the places that is needed. > Maybe there should be some mechanism for allowing inner=20 > macrodefs for inheriting attributes from an outer macrodef. =20 > Maybe elements should be able to be defined with nested=20 > attributes. Or something. >=20 This will not solve your problem. Your problem is that you are using ${war.webxml} on target make.admin.war and there is no property defined at that point in time. Jose Alberto > But this experience with trying to use this feature leads me=20 > to the feeling that using the same notation for macrodef=20 > attributes and ant properties is not a good thing. It will=20 > definitely cause confusion. At a minimum more documentation=20 > of this is required. >=20 >=20 > > > > =20 > target=3D"create.precompiled.web.xml"> > > value=3D"${dest.web.xml}"/> > > > >=20 > =20 > > > > >=20 > > > > =20 > > =20 > =20 > =20 > =20 > > > token=3D"#build#" =20 > value=3D"${project.version}.${project.maintenance.build}.${proje ct.fix.build}"/> > webxml=3D"${war.webxml}" > basedir=3D"${war.basedir}"> > > > > =20 >=20 >=20 > depends=3D"make.precompilation" > work.dir=3D"${dir.admin.ear}" > =20 > war.webxml=3D"${dir.build.precomp.webxml}/${admin.web.xml}" > war.basedir=3D"${dir.admin.ear}/temp" > war.destfile=3D"${dir.admin.ear}/war/${admin.war}"> > > =20 > src.web.xml=3D"${dir.src.web.xmls}/${admin.web.xml}" > dest.web.xml=3D"${war.webxml}" > /> > > > > > > > > >=20 >=20 >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org