ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <gus-ant...@cognition.olin.edu>
Subject Re: failonerror; general solution
Date Thu, 09 Oct 2003 19:18:46 GMT
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" <jalberto@cellectivity.com>
>À : "Ant Developers List" <dev@ant.apache.org>
>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:Emmanuel.Feller@free.fr]
>>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" <jalberto@cellectivity.com>
>>À : "Ant Developers List" <dev@ant.apache.org>
>>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: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message