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]
