ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [new tasks] presetdef and macrodef
Date Tue, 19 Aug 2003 17:47:15 GMT
> From: peter reilly [mailto:peter.reilly@corvil.com]
> 
> On Thursday 14 August 2003 17:44, Dominique Devienne wrote:
> > > -----Original Message-----
> > > From: peter reilly [mailto:peter.reilly@corvil.com]
> > >
> >
> > >
> > > All of the expansions happen later on.  If the macro is used in a
> > > different project to the project it is defined in, the 
> properties in
> > > use will be of the project that the macro is used in*.
> >
> > Which is exactly why I don't like using the same syntax,
> which until
> > now
> > *always* expanded as if at the place of definition/use!!!
> 
> What I am saying is that even with a different notation for
> attributes, normal property resolution will take place in the 
> context of the user of the macro, and not when the macro is 
> defined. This is a consequence of the way <macrodef/> is 
> implemented, in particualar to support embedded elements.
> 

Now that you explained this, I would really like to have a way
of defining properties that are expanded at definition time.
I do not know if it can be done with the syntax we already have
or we need something diferent. Probably we do, since we would need
a way to distinguish between inlined (replace during definition)
and not inlined (replaced during evaluation) properties.


> >
> > > However, I can see
> > > that there can be issues with using the same notation for 
> the macro 
> > > expansion of attributes and then normal expansion of properties.
> >
> > So we're you planning on refusing 'normal' property expansion in 
> > <macrodef>? If two different syntax are used, it's obvious what's 
> > what.
> >
> > > I am loath however to adding new rules for indicating variables. 
> > > However if ant people want a different encoded for the macro 
> > > variables, I would have no objection.
> >
> > OK, let's see:
> > 1) Introduce a new syntax (@name) for a new feature,
> >    thus keeping the existing syntax ${name} its only behavior
> > 2) Overloading the existing ${name} syntax to behave differently
> >    in <macrodef>
> >
> > It's a no brainer to me. I clearly vote for (1).
> 
> As a temporary measure I have added a new attribute 
> "attributestyle" to allow the notatation to be specified. The 
> attribute can be "ant"  (default) or "xpath". This should 
> allow people to experiment with either formats, and we could 
> choose one later.
> 

I think this is the worst thing to do. Having flavors of the task will
only
cause confusion I am afraid. We should hash out our differences and
stick to one syntax.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message