ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: executing task for each file in file set
Date Fri, 15 Jun 2001 09:07:46 GMT
Jose Alberto Fernandez <j_a_fernandez@yahoo.com> wrote:

> So the aim is to: given a set of values apply XYZ to them.
> 
> Question 1) What should XYZ be?
> 
> There has been various proposals on this:
> 
> a) a <target> which is what the contributed <foreach> task does.
> 
> b) a group of <task>s, with a construct that allows the embedding of
> tasks as elements.
> 
> c) a <task>, by adding some predefined support to the abstract Task.
> 
> d) a <antcall>, which will allow something simillar to application
> to <target> but within its own execution context.

(c) is the only thing that would require changes to the core, so it is
the one I like the least.

If you nest antcall into (b) you get (d) - so (b) is wider applicable
than (d).  At some point during discussion about Ant2 we've more or
less agreed that there'll be an antcall version that doesn't use an
execution context of its own - so that would cover (a) as well.

> I would prefer to stay away of any approach that requires changing
> the values of properties within the same execution context. Why?
> because I think that would make any paralellizable execution
> approach very difficult to achieve.

Sure it would, but this is the problem of the people using this
construct, isn't it?  Parallel property access is one of the smallest
problems I see with parallel execution of tasks.

> It will also bring into place the need to define what would be the
> values of such properties at the end of the set application.

Same again.  A apply-to-set task would have to clean up any additional
properties (like an iterator or something) it uses as helpers at the
end IMHO.

> Question 2) how to describe the set of values?
> 
> It looks to me like we may need to have some "Set" interface
> implemented by <fileset> and others on which the application occurs,
> is that part of ANT2 already?

Not explicitly, but we have set-operations on the feature list.  It
would be quite cumbersome to write a set-union task for each set type
Ant supports - having a generic Set interface would improve the
situation a lot.

> Question 3) What should be the syntax?

Depends a lot upon the answer to Question 1).

You are going quite a long way to avoid task-scoped properties, aren't
you?

> (1)
> 	<task  att1="..." attr2="..." ... >
> 	  <applyto attribute="attr3">
> 		<fileset .... />
> 	  </applyto>
> 
> 	  <element1 .....>
> 	  <element2 .....>
> 	</task>

In option (b) of your Question 1:

<applyto property="member">
  <task  att1="..." attr2="..." attr3="${member}">
    <element1 .....>
    <element2 .....>
  </task>
</applyto>

> (2) 
>       <task att1="..." attr2="..." ... > 
>         <applyto element="element3" attribute="elemAttr"
>                  fixpart="...."  all="false" > 
>           <fileset .... />
>         </applyto> 
>         <element1 .....> 
>         <element2 .....> 
>       </task>

<applyto property="member">
  <task  att1="..." attr2="...">
    <element1 .....>
    <element2 .....>
    <element3 your-fixpart-attributes-here elemAttr="${member}" />
  </task>
</applyto>

> What should be the position of the application with respect to other
> elements?

No problem if you allow task-scoped helper properties.

> Now, two interesting aspects here is that in some cases the inner
> element has more than one attribute that needs to be set, like the
> case of <param> in <ant*>. On those cases one needs a way to pass
> the fixed part of the element definition. That is what I am doing
> with "fixpart". I am open to better solutions.

See above.  You didn't even cover the case where you need access to
children of child elements, which would fall out of "the other" syntax
without any problem.

> Does it make sense to allow for more than one "applyto" element?
> (cartesian product) Or would that just make the semantics too
> complicated for confort.

No real problem with the approach (b) of your Question 1 either.
applyto would be a task, so it can certainly be nested into another
applyto as well.

Stefan

Mime
View raw message