ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: Augment task and use cases
Date Thu, 01 Jul 2010 15:26:02 GMT

On Jul 1, 2010, at 9:52 AM, Michael Ludwig wrote:

> I'm wondering about the design of the Augment task, which uses
> augment/@id instead of augment/@refid to refer to an existing
> resource. To draw on the example from the manual:
>
>           \,,,/
>           (o o)
> ------oOOo-(_)-oOOo------
> Given
>
>   <fileset id="input-fs" dir="${basedir}" />
>
>   <augment id="input-fs" excludes="foo" />
>
> Modifies the excludes attribute of input-fs.
>
>   <augment id="input-fs">
>     <filename name="bar" />
>   </augment>
>
> Adds a filename selector to input-fs.
> -------------------------
>
> But how is this supposed to be used? A couple of times, I saw  
> <augment>
> nested inside <sequential>. Still, I'm getting errors such as:
>
> * pathconvert doesn't support the nested "augment" element.
> * pathconvert doesn't support the nested "sequential" element.
> * fileset doesn't support the nested "augment" element.
>
> Wouldn't it be nicer to have <augment>, which is still young and
> flexible, have augment/@refid to refer to an existing reference, and
> augment/@id to present an ID of its own so it can be referred to by
> other tasks?
>
> Or is there something obvious that I'm overlooking?

TBH, there is really nothing "obvious" *about* this task.  ;P  It  
hooks into Ant's internal configuration mechanisms to modify  
attributes and add nested elements, so any attribute permissible on  
the referenced object, including refid where applicable, is fair  
game.  In this way you could theoretically modify the 'refid'  
attribute of some reference type to point to a new target.  What this  
means is that 'id' is really the only "safe" attribute name for its  
purpose, by virtue of the fact that it is interpreted by Ant not to  
map onto the task/type, but as a key into a Project's internal  
reference table (except when <augment> hijacks it).  But yes, one  
effect of this is that you don't declare a reference to an <augment>  
task instance.  Honestly, though, I can't think under what  
circumstances this would even be desirable.  The vast majority of  
tasks do not support declaration by id and subsequent re-invocation.   
To address your errors e.g. pathconvert doesn't support the nested  
"augment" element:  pathconvert's documentation, I expect, makes no  
assertion that you can nest a task inside pathconvert.  The intended  
usage of <augment> is:  1. declare a reference; 2. augment it as many  
times as desired; 3. use the reference as though you had declared it  
this way all along.  I hope this clears up some of your confusion.

-Matt

> -- 
> Michael Ludwig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>


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


Mime
View raw message