You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Michael Ludwig <mi...@gmx.de> on 2010/07/01 16:52:12 UTC
Augment task and use cases
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?
--
Michael Ludwig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Augment task and use cases
Posted by Matt Benson <gu...@gmail.com>.
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: 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
Re: Augment task and use cases
Posted by Michael Ludwig <mi...@gmx.de>.
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
Re: Augment task and use cases
Posted by Matt Benson <gu...@gmail.com>.
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