ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: Augment task and use cases
Date Thu, 01 Jul 2010 17:02:05 GMT

On Jul 1, 2010, at 11:07 AM, Michael Ludwig wrote:

> Matt Benson schrieb am 01.07.2010 um 10:26 (-0500):
>> On Jul 1, 2010, at 9:52 AM, Michael Ludwig wrote:
>>> 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?
> What I was overlooking is that <augment> *modifies* an existing  
> resource
> instead of taking it as the basis for a *new* resource, which it would
> then be useful to refer to using @id and @idref.
>> 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.
> I see.
>> 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).
> Got 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.
> That was my misunderstanding, as explained above.
>> 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.
> It doesn't; it requires an @idref to some @id. I just didn't see you
> would use the @id of the original resource, as I thought a new one  
> would
> have been created by <augment>.
>> 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.
> It thoroughly does. Thanks! Here's a trivial example of how I think it
> might be used, corrections or suggestions welcome:

These examples all look reasonable.  I had encountered situations  
over the years where something like this would have been nice, and  
made at least one false start in the direction of accomplishing  
similar goals.  When I finally came up with the idea for the current  
implementation of <augment> my motivation at the time was using Ant's  
new extension functionality.  Being able to <augment> a given  
fileset, etc. in an extended build provides a simple way to establish  
conventions in your included buildfiles, yet be able to override  
certain behavior in your build when necessary.


> <project default="a">
>  <!-- original resource -->
>  <fileset id="fs" dir="${basedir}" includes="z*.xml"/>
>  <augment id="fs"><!-- modify it -->
>   <include name="LIESMICH.txt" />
>  </augment>
>  <target name="a"><!-- modify it if we get here -->
>   <augment id="fs"><include name="a*.xml" /></augment>
>   <pathconvert pathsep="${line.separator}" property="pc" refid="fs"/>
>   <echo message="${pc}"/>
>  </target>
>  <target name="c"><!-- ditto -->
>   <augment id="fs"><include name="c*.xml" /></augment>
>   <pathconvert pathsep="${line.separator}" property="pc" refid="fs"/>
>   <echo message="${pc}"/>
>  </target>
>  <target name="jar"><!-- ditto -->
>   <augment id="fs"><include name="*.jar" /></augment>
>   <pathconvert pathsep="${line.separator}" property="pc" refid="fs"/>
>   <echo message="${pc}"/>
>  </target>
> </project>
> -- 
> Michael Ludwig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message