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: [email protected]
For additional commands, e-mail: [email protected]
