ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Feller" <Emmanuel.Fel...@free.fr>
Subject Re: failonerror; general solution
Date Thu, 09 Oct 2003 14:07:00 GMT

----- 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


Mime
View raw message