Very interesting point of view. 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.
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. 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. Jose Alberto > -----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. > > > > > -----Original Message----- > > From: Emmanuel Feller [mailto:[EMAIL PROTECTED] > > Sent: 09 October 2003 12:26 > > To: Ant Developers List > > Subject: Re: failonerror; general solution > > > > > > Hello, > > > > I not agree on all ... > > > > The <if/> is not a good thing, and especially in big > builds. > > My builds are quite comlex and I reduce complexity by > developping my > > own tasks : this is the official way and > > (IMHO) should be promoted. I developped wrapper around conditionnal > > things but now I have access to macro by <macrodef/>, and I think i > > will refactor my build around this. So i think than the > <if/> has no > > place in ANT any > more, > > if it could had one. The same things for <foreach/>. > > > > I think than Ant 1.6 is a quite revolution (cleaner ways, simpler > > ways), so i do not want it to be misunderstood.(In > My > > Humble Opinion) > > > > I use the try/catch, and it could be shipped but I do not > want that it > > convince newbies than Ant is a scripting framework. It is a real > > danger. > > > > For the propertyCopy, i use it a lot, but i am searching a > cleaner way > > to do it. On this i do not have an opinion. > > > > Emmanuel > > ----- Message d'origine ----- > > De : "Jose Alberto Fernandez" <[EMAIL PROTECTED]> > > À : "Ant Developers List" <[EMAIL PROTECTED]> > > Envoyé : jeudi 9 octobre 2003 12:59 > > Objet : RE: failonerror; general solution > > > > > > To tell you the truth I think that the 5(?) tasks of antcontrib are > > just a necesity if you try to write large ANT scripts that must be > > maintainable by more than > one person. > > > > The <if/> task helps reduce the amount of temporary > > variables ant > > special init-targets and intermediate targets whose only > > need is to > > check for a property being set or not. > > > > <trycatch/> speaks for itself. > > > > In my builds, at least, <foreach/> is a necesity, since > many > > of my > > modules > > must be build several times with different configuration > parameters. > > And the number of configurations is > configurable. > > > > The other ones, <propertycopy> and others are just good. > > > > This is why I think we should ask for permission to ship > it > > as an > > antlib. > > It will serve as an example of the power of the framework. > > > > > -----Original Message----- > > > From: Gus Heck [mailto:[EMAIL PROTECTED] > > > Sent: 08 October 2003 19:58 > > > To: Ant Developers List > > > Subject: Re: failonerror; general solution > > > > > > > > > > > > >I'm not as eager to see the tasks in Ant proper as > > others, > > > that's why I > > > >haven't taken any initiative here (in Apache speak, > > that's the > > > >difference between my +0 and the +1s that have been > cast > > by others). > > > > > > > > > > > > > > > Are we talking about all ant-contrib tasks or just > > try/catch? > > > I thought > > > just try/catch... > > > > > > -Gus > > > > > > > > > > ---------------------------------------------------------- > > ----------- > > > 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] > > > > > > > > > > ---------------------------------------------------------- > ----------- > > 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] > > > > > --------------------------------------------------------------------- > 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]
