ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: executing task for each file in file set
Date Fri, 15 Jun 2001 11:23:50 GMT
Stefan,

thanks for your comments. Let me first say that I am open here. I am just
trying to get a discussion going and trying to teased people into thinking
whether we need this at all and if we do how it should look like.

So here are some comments...

> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> 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.
>

Did we agreed to that? I thought we were talking about nested <tasks>, but
not about some other <antcall> behaviour.

In any case, I am not sure the set-application feature should be judge
completely on how much it can cover, in particular I am not sure the 4
posibilities above are neither the only ones nor the right ones, they are
just the current ones :-).

I would like to also take into consideration things like what restriction it
may impose on the ANT engine. I would like, whatever solution we get, to be
as loose in that regard as possible. So that future ANTs have a chance to do
more interesting or clever things. Notice that on this point I would
consider the requirements for user tasks to be very different from those of
the ANT control primitives: <target>, <ant*>, "depends", or whatever we come
up with here. The later define the meaning of the buildfile, the former
(even if a CORE task) will always depends of the actual tools being invoked
by those tasks (some can be improved, others do not).


> > 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.
>

That is exactly my point, if the construct is badly defined, and there is no
alternative to the build writer, we can't hardly blame him for having used
it. It is up to us, to define the feature in such a way to minimize future
"problems". Worst that parallel access, it is parallel modification of the
execution environment. If the construct allows that, then it will be very
difficult to achieve parallelism or some other execution paradigm we may
think of in the future.

> > 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.
>

Right. What happens if "iteration property name" has been defined before?
(Can I reuse that name, i.e., local variable). Can the task(s) inside the
construct define properties visible at the end? e.g., doing an <available>
loop? What do we do if they apply to the same property name?

> > 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.
>

Sure, the "set" interface does not necessarily need to be visible to users.
Although, it may be difficult to explain what kind of "types" can be used in
an <union> if we do not have some unifying concept. So it seems it will have
to show up at least as a documentation concept.

> > 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?
>

Hey, I am trying to start a row (I mean a discussion :-) ).

> > (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>
>

Yeap. These are strong points for (b). Well, nested constructs have been the
basis of modern programming languages for a reason :-) (you forgot defining
the set (fileset) somewhere in your syntax, btw -- no harm done).

> > 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.
>

Yeap, nested constructs are powerful. But if we go that way, what stops us
from having the same argument about <if><else> (or maybe
<choice><case></choice>) type of constructs?  Do we really want to go that
way? (I am really asking). How about all the arguments about "if" at task
level? Whouldn't these constructs be doing exactly the same? Do we still
believe they are bad, while <applyto> is more acceptable?

I just want to come up with some consistent set of argument to use in
evaluating all these issues.

And to add more logs to the fire, let me bring to the front one more thing
;-)

In ANT we have come up with a pattern for calling a subroutine which is
based on <antcall> and the definition of <target>s. In many cases, the
target have been artificially defined just to group a buch of tasks
toguether so that we can perform some repetitive set of tasks by passing
some parameters.

Wouldn't it make more sense to replace these artificial targets and allow a
proper declaration/call of procedures? (with a stack, local scope and so
on -- which we already support in the core). Something like:

	<procedure name="xzy">
	  <property name="local" value="local to the call" />
	  <task1 ..${tw}../> <!-- a global or parameter -->
	  <task2 ..../>
	</procedure>

	<target ..... >
	 <call name="xzy" >
	  <param name="tw" value="parameter value" />
	 </call>
	 <task3 ...../>
	</target>

Should they be allow to return properties (return values)? Is that a method?

	<method name="123" returns="localresult" >
	  <task ...../>
	  <property name="localresult" value="myResult" /> <!-- or available -->
	</method>

	<target ....>
	 <call name="123" property="myProperty" />
	 <echo message="${myProperty}" /> <!-- prints "myResult" -->
	</target>

"procedure", "method", "subroutine", "proc" pick just one name for all.

I think something or this sort would make buildfiles more clear. And easy to
understand.

Should we have it, should we not? What should be the principle behind our
answer?

Jose Alberto

> Stefan
>


Mime
View raw message