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