On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> > > Things we need to consider IMHO:
> > >
> > > (1) Syntax
> > >
> > > Your proposal uses a <local> task that sets up a local scope for a
> > > named property until the enclosing target/sequential
> >
> > finishes. Jose
> >
> > > Alberto suggested to use a <local> TaskContainer instead, something
> > > like
> > >
> > > <local>
> > > <local-property name="...."/>
> > > </local>
>
> Just for the record, my syntax was more like:
>
> <local property="...." [value="...."]>
> ...
> </local>
>
> Which does not need inner special elements (less clumsy) but it
> requires one nesting per property (but really, how many locals
> would you have one after the other?)
>
> > > which would essentially just add an explicit (and
> >
> > differently named)
> >
> > > <seqential> to your proposal. I think I prefer the more explicit,
> > > even if more verbose syntax of the second form.
> >
> > I think that this looks clumsy. Making local's valid for the
> > current block scope (target level, or sequential level) feels (to
> > me) more natural. However, I can see benefits ;- my code may
> > not catch all uses of sequential.
>
> My major issue with the current implementation proposal is that
> it touches way too many places in the code. It needs to change the
> implemention of almost all the usages of sequential (and target).
This is not quite true. It does change the implementation of
target and task but usage of these should not need to change.
For example ant-contrib has a <outofdate> task with a <sequential>
element. This works correctly as a local block without any changes to the
implementation of Outofdate:
<target name="outofdate">
<local name="l" value="outer"/>
<ac:outofdate>
<ac:sourcefiles/>
<ac:targetfiles path="file-not-present"/>
<ac:sequential>
<local name="l" value="in outofdate"/>
<echo>l is '${l}'</echo>
</ac:sequential>
</ac:outofdate>
</target>
prints out "l in 'in outofdate'".
> In my design it should only touch <local> itself and the datastructures
> for property handling (given that we want to use threadlocals).
>
> It is a very much less footprint and that I think is good.
>
> > (note as well that local-property is not a valid name,
> > localproperty would be correct).
> >
> > > (2) Shadowing of properties
> > >
> > > Your updated proposal ensures that local properties do not override
> > > "global" user properties. I think they shouldn't be allowed to
> > > override any outer scope properties at all.
> >
> > I think that this will reduce their usefullness a lot. The
> > idea of not overridding user properties comes from the <ant>
> > family behaviour, but they can overriden other properties.
>
> Agreed, if I cannot override properties, what was the point of all this
> discussion?
> The proposal always allowed to override properties.
>
> > > (3) Extent of local properties
> > >
> > > You make the local properties available to <script> - will
> >
> > they also
> >
> > > be available for builds that get called with the <ant>
> >
> > family of tasks
> >
> > > (assuming inheritall is true)? I think they should be.
> >
> > Yes this is implemented.
>
> Can we make sure that all the tasks that are based on <ant>
> will automagically get this done right? This I think is my major
> fear in all this, that 3rd party <foreach> and co. will not work
> correctly.
The change to ant should work for 3rd party <foreach> and co, it is
done with the other common property handling code in Ant.java. (It does
for example work with ant-contrib foreach without changes to the
implementation of foreach).
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
