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
|