ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <mil...@gmx.de>
Subject Re: Augment task and use cases
Date Thu, 01 Jul 2010 16:07:18 GMT
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:

<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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message