RE: PATCH: Attributes of Target can reference properties

[Peter Vogel <pv...@arsin.com>]

Peter D -- I think you need to rethink your position.  While templating is
nice, and I amy even use it in the future, blocking progress of base ant
in this manner will only lead to ant becoming a boat anchor when people
stop being amazed by the javac task and start using it for building 
real *systems*.

That or a fork...  (which I *really* don't want to do) 

Just look at how many people post to this list with problems that would 
be solved by a few simple features which are repeatedly blocked by a few 
select committers:
	foreach
	if
	expansion of variables in the depends attribute
	
The simple fact of the matter is that the *goals* you purport to support 
(simplicity, avoidance of obfuscated constructs, etc.) are laudable, but
quite frankly I'm mystified by your approach: you block the very constructs
that would help to avoid monstrosities such as these:

<target name="a">
    ...
</target>
	
<target name="b">
    ...
</target>

<target name="c">
    ...
</target>

<target name="d">
    ...
</target>

<target name="doall" depends="a,b,c,d"/>

Where the ... is the same in all cases other than its use of some feature
distinguished by the target name.  How much easier it could be:

<target name="doall">
    <foreach var="loopvar" list="a,b,c,d">
         ... (using ${var})
    </foreach>
</target>

Or consider the property referencing patch that is the core of the current
topic, I can *completly* abstract the common build tasks into a core of 
files (property.xml and target.xml) and use them in subsystem build.xml 
files (as posted previously) but I need for the local level to be able to
override or augment things done in the standard build phases.  For example
target.xml has constructs like this:

<property name="dist" value="global.dist"/>

<target name="dist" value="${dist}"/>

Which allows a local file to do this before including target.xml:

<property name="dist" value="local.dist, global.dist"/>

or this if the dist target doesn't make sense in this subsystem:

<property name="dist" value="noop"/>

>From my POV, your templating concepts ADD complexity for very little
value...

 
-Peter

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Friday, June 22, 2001 5:01 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: PATCH: Attributes of Target can reference properties
> 
> 
> Peter Donald <do...@apache.org> wrote:
> 
> >> So you say you are going to -1 every solution that allows users to
> >> specify dependencies on the command line for Ant2 and offer
> >> templates as the alternative.  You'd accept such a non-templating
> >> solution for Ant1, as long as it doesn't imply it will be present
> >> in Ant2.  Is this correct?
> > 
> > essentially ;)
> 
> In which case we are stuck with regard to Peter Vogel's patch, targets
> will be there in Ant2 and they will have a depends attribute -
> expanding properties for it in Ant1 but not for Ant2 is not an option
> for me.
> 
> Stefan
> 

Re: PATCH: Attributes of Target can reference properties

[Peter Donald <do...@apache.org>]

On Tue,  3 Jul 2001 18:13, Peter Vogel wrote:
> Peter D -- I think you need to rethink your position.  While templating is
> nice, and I amy even use it in the future, blocking progress of base ant
> in this manner will only lead to ant becoming a boat anchor when people
> stop being amazed by the javac task and start using it for building
> real *systems*.

I assume you are trolling. The questions you ask have been discussed in past. 
Besides quite a few "real" systems are built today using ant. 

And just FYI it was Stefan who blocked this not me ;) I just said I will -1 
for Ant2.

> From my POV, your templating concepts ADD complexity for very little
> value...

Well for one it adds the ability of foreach/if/ etc that you seem to want?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: PATCH: Attributes of Target can reference properties

[robert burrell donkin <ro...@mac.com>]

(...putting flame-proof boots on...)

On Tuesday, July 3, 2001, at 09:13 AM, Peter Vogel wrote:
<snip>

> Just look at how many people post to this list with problems that would
> be solved by a few simple features which are repeatedly blocked by a few
> select committers:
> 	foreach
> 	if
> 	expansion of variables in the depends attribute

<snip>
(apologies if the previous paragraph isn't representative of your position)

once you go down the road of introducing features that more right belong 
in scripting languages, where are you going to stop?

have you ever thought that a better way to solve your problem might be to 
generate your build scripts?

that way you can use a proper, fully functional scripting language such as 
velocity to design your templates. when you run the main build script, use 
(for example) the texen task to generate your specialized build script 
from your template and run the generated script all from within ant.

- robert

Re: PATCH: Attributes of Target can reference properties

[robert burrell donkin <ro...@mac.com>]

(darn empty post... sorry)

- robert

Re: PATCH: Attributes of Target can reference properties

[robert burrell donkin <ro...@mac.com>]

On Tuesday, July 3, 2001, at 09:13 AM, Peter Vogel wrote:

> Peter D -- I think you need to rethink your position.  While templating is
> nice, and I amy even use it in the future, blocking progress of base ant
> in this manner will only lead to ant becoming a boat anchor when people
> stop being amazed by the javac task and start using it for building
> real *systems*.
>
> That or a fork...  (which I *really* don't want to do)
>
> Just look at how many people post to this list with problems that would
> be solved by a few simple features which are repeatedly blocked by a few
> select committers:
> 	foreach
> 	if
> 	expansion of variables in the depends attribute
> 	
> The simple fact of the matter is that the *goals* you purport to support
> (simplicity, avoidance of obfuscated constructs, etc.) are laudable, but
> quite frankly I'm mystified by your approach: you block the very 
> constructs
> that would help to avoid monstrosities such as these:
>
> <target name="a">
>     ...
> </target>
> 	
> <target name="b">
>     ...
> </target>
>
> <target name="c">
>     ...
> </target>
>
> <target name="d">
>     ...
> </target>
>
> <target name="doall" depends="a,b,c,d"/>
>
> Where the ... is the same in all cases other than its use of some feature
> distinguished by the target name.  How much easier it could be:
>
> <target name="doall">
>     <foreach var="loopvar" list="a,b,c,d">
>          ... (using ${var})
>     </foreach>
> </target>
>
> Or consider the property referencing patch that is the core of the current
> topic, I can *completly* abstract the common build tasks into a core of
> files (property.xml and target.xml) and use them in subsystem build.xml
> files (as posted previously) but I need for the local level to be able to
> override or augment things done in the standard build phases.  For example
> target.xml has constructs like this:
>
> <property name="dist" value="global.dist"/>
>
> <target name="dist" value="${dist}"/>
>
> Which allows a local file to do this before including target.xml:
>
> <property name="dist" value="local.dist, global.dist"/>
>
> or this if the dist target doesn't make sense in this subsystem:
>
> <property name="dist" value="noop"/>
>
> From my POV, your templating concepts ADD complexity for very little
> value...
>
>
> -Peter
>
>> -----Original Message-----
>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>> Sent: Friday, June 22, 2001 5:01 AM
>> To: ant-dev@jakarta.apache.org
>> Subject: Re: PATCH: Attributes of Target can reference properties
>>
>>
>> Peter Donald <do...@apache.org> wrote:
>>
>>>> So you say you are going to -1 every solution that allows users to
>>>> specify dependencies on the command line for Ant2 and offer
>>>> templates as the alternative.  You'd accept such a non-templating
>>>> solution for Ant1, as long as it doesn't imply it will be present
>>>> in Ant2.  Is this correct?
>>>
>>> essentially ;)
>>
>> In which case we are stuck with regard to Peter Vogel's patch, targets
>> will be there in Ant2 and they will have a depends attribute -
>> expanding properties for it in Ant1 but not for Ant2 is not an option
>> for me.
>>
>> Stefan
>>
>