Re: failonerror; general solution

[Gus Heck]

Reading this thread I am beginning to think that there is a fundamental 
problem on the road ahead for ant. If I understand correctly, one of the 
founding Ideas of Ant was that builds were something that should be 
described, not programed. Since I have joined this list about 1.5 years 
ago, I have seen a lot of stuff added and proposed that reflects a 
strong desire on the part of (at least some) users to construct builds 
that are programatic (often refered to as scripty), using if/unless 
tags, control properties, <script>, <macrodef> etc. I also have seen 
countless requests for the features delivered by ant-contrib, or at 
least suggested resolutions that involve ant-contrib.

Im wondering if part of what is happening is a migration of what people 
need from a build tool... Or is it just a matter of people remembering 
things they did with scripts and not shifting their way of thinking. I 
don't actually work in the real world. I am nice and cozy  and insulated 
from "real" builds. I live in the mini-world of a grant that so far 
mostly involves only lightweight java development of smallish peices of 
code, and does not deploy any single cohesive software product, aside 
from a web site (which I do use ant to build from a CVS repostiory and 
maintain).

So from the perspective of larger projects and the deadline driven 
commercial ("real"??) world, have the needs really changed?

If so, should ant change? Or should a new tool/build language be 
developed? Or perhaps there should be flavors of ant such as ant-lite 
and an ant-full? As it stands we are getting a fair hodgepodge of tasks 
that have if/unless and macrodef is awfully close to procedural 
programming. I think that leaking in the scripty stuff slowly is not 
such a good idea, and if we are going to let people "program their 
build" we should be designing with that in mind, not as an afterthought.

I kinda think Ant's cross platform portablility is likely to be the 
feature most valuable to the users, but I could be wrong there.

Anyone else have similar thoughts?
-Gus

Emmanuel Feller wrote:
----- Message d'origine ----- 
De : "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
À : "Ant Developers List" <[EMAIL PROTECTED]>
Envoyé : jeudi 9 octobre 2003 15:30
Objet : RE: failonerror; general solution

 

Very interesting point of view.
   

thanks ;))
 

I see what you are saying, but I do not think that one
   

should
 

try to force people to do things one way (the way someone
   

likes)
 

by just vetoeing all other ways, which may be more
   

convinient to others.
not vetoing, but as you know, many users do not read "the
fucking manual" ... as I did before my deep entrance in Ant
utilisation. So if you put the necessary stuff in your core,
will you search to understand a quite difficult philosophy
and method ? no, i do not think so.
 

Changing to the topic of java-logic vs. task-logic in
   

buildfiles,
 

it all depends whether you want/like/need hard binding or
   

loose
 

binding in your builds. By that I mean, when using java you
   

are hiding
 

what really goes on in a backbox, that must be maintained
   

independently.
 

If you need to change the way the build works, you may
   

finish needing
 

completely diferent tasks that need to be rewritten in
   

java.
 

I prefer not to go to java, if I can. We have done several
   

reorganizations
 

of our deployment strategies which required completely
   

different
 

ways to perform the build, and there was no java changes
   

involved.
This is exactly why I speak of ANT 1.6 revolution : macro
and preset !
These task are wonderfull and many problem will be solvable
without Java developpement.
 

Now my only point is that just because some people prefer
   

deepbinding
 

it does not mean that loosebinding is wrong. It is just a
   

different
 

way of doing things. And I do not think one is worst than
   

the other.
I do not say it is wrong, but it is not the official way. As
you could see, when i answer to a user request (i do not
have lot of time to do :( ), i propose everytime two way :
an "official" point of view and a quick solution (like
foreach).
I think (but it's my opinion) than ant should not provide
stuff for unofficial way, because you risk to mix the image.
 

Jose Alberto
   

Emmanuel
 

-----Original Message-----
From: Emmanuel Feller [mailto:[EMAIL PROTECTED]
Sent: 09 October 2003 13:29
To: Ant Developers List
Subject: Re: failonerror; general solution
I am not saying that everyone should redesign wheel
   

because
 

ant is not script ...
I was like you tired of the scripting tabu, but i review
   

my
 

opinion when i had to do my first very complex build file.
The scripting way was not the description way and i found
   

a
 

wall when i developped the scripting way, because i miss
description details in my process.
I am saying that :
You should not take a solution because it exists but
   

because
 

you need really it. I might that every project are
   

differents
 

and that task are the basics element of construction game.
Now your project drive the way you build, you should take
care on patterns but not apply a solution because marked
   

as
 

THE solution.
My builds are less complex still I developpe my own task,
because i use all basic stuff in my context.
So you may developp a script with foreach, if, and every
task. It will be long and may be not efficicent.
Me I developp a task that verify if uptodate, compile, jar
and javadoc my basic element of project.
It is only a wrapper on ant core task ... no
   

redeveloppement
 

of basic things but value added things.
And after i have a task that ask my scm for modules names
and location and call the previous task.
(I am migrating my task within macro).
This is one of my targets. My build file are quite short
(around 2000 lines with comments), and are simple to
   

maintain.
 

I took time to understand (around 1year) but now i think
that i am efficient on build process.
Newbies may not have abstraction point of view if we
   

provide
 

the scripting features. Only my opinion, Emmanuel
----- Message d'origine ----- 
De : "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
À : "Ant Developers List" <[EMAIL PROTECTED]>
Envoyé : jeudi 9 octobre 2003 14:03
Objet : RE: failonerror; general solution

So are you saying that instead of having access to generic
things in ANT that anyone can use, we should prefer having
every user defining it own little dialect with his own
   

little
 

tasks for minor things that everybody needs. (I.e., I do
   

not
 

think anybody denies the need for doing things
   

conditionally
 

on the build).
I find this very strange.
I have my own tasks too, but this are tasks for our
   

inhouse
 

code generator and such which are specific to our
   

environment
 

(so I am not afraid to define them), I also have my own
<forall/> tasks which works diferent than the <foreach/>
   

of
 

antcontrib. But why you want every user to reinvent <if>,
etc. It makes no sense to me. (At the end we get
   

enhancement
 

request after enhancement request, for ways of doing
   

things
 

that can be done using this simple tasks, efficiently.
I do not think the aim of ANT is to require people to
   

write
 

java code for every other thing they need in their build.
   

The
 

point of ANT and ANTLIB in particular is to provide
   

reusable
 

tasks that anyone can use. If you do not like a certain
   

group
 

of tasks, well do not use them, but that does not mean
vetoeing anyone else to use them.
And as I have said several times now, I am not asking for
them
to be added to core, I an just asking them to be shippen
   

as
 

a
useful antlib that people can use in their builds, if they
   

want.
 

Jose Alberto
PS: I am so tired of the "ANT should not be a scripting
language" tabu when in reality it is, just like MAKE or
   

any
 

other description language that gets executed. ANT is not
   

a
 

procedural language, that I agree, but it is a script.
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]