> From: Peter Donald [mailto:[EMAIL PROTECTED] > > At 03:56 PM 5/28/01 +0100, Jose Alberto Fernandez wrote: > >I got to say, I am very -1 on going the way of make and > getting on the > >bussiness of an autoConfig sort of way of solving problems. > I do not see the > >need for that. > > You have said that a couple of times but never given any > reasons. Can you > give some reasons. > > Without this we will require that ant include > if/case/condition/* style > tasks that are a declared non-goal. Simply because we need > the flexability. > I have already had to fight often enough with some of ants > rules that it > gets painful for large projects. >
With this *YOU ARE* adding if/case/condition* to ANT. Even more you are adding an additional syntax and semantics for writing buildfiles. Lets face it, if it is jakarta-ant defined and maintained, it is ANT. The beauty of ANT is its simplicity which allows peoples to understand ANT's files with only basic knowledge of ANT itself. This new language for autoConfig will break that, and I think that is bad. I definetly do not want to have 100 pages of the ANT documentation explaining how XSLT templates work. Certaintly there are books dedicated to the subject that are fatter than that, so it is not just a retorical statement. > As most committers agree that making ant a script language is > a bad idea > then we have a problem. Certain stages of build process need > ad-hoc logic > (aka scripting) - namely the first stage of detecting > environment. So we > either make people jump through loops (yuck), add scripting > to ants core > (yuck) or make it accessible through another stage (yea!). > How is a pure Java autoConf going to solve this. I mean where are all this configuration parameters for the different configurations comming from. Aren't you just trying to add conditionals in desguise? Can you give examples of the kinds of real world issues that you think can only be solved properly by autoConf? > So if you can think of a way to solve the problem then we throw away > separate configure stage. If you can convince the committers > that we don't > need to support complex build environments then we can > throwaway the stage. > Otherwise I can not see any other alternative considering the > goals of ant. > Can you provide some realistic scenarios? What is what you think is impossible (or very unintuitive) in ANT (or ANT2's proposal). My current thoughts about it is that people feel autoConf is needed and fill includes and mutable properties are needed because we are use to MAKE and the patterns developed over time for MAKE and we want to apply those same patterns in ANT. I would argue that ANT has (or will develop) its own patterns in which mutable variables, textual includes, and I think autoConf are not needed. This, of course, involves a paradigm shift of proportions I don't really know. But I think this is a very important aspect of the ANT future success. Like with any other programming tool, the success of maintainability and expressibility relies on the patterns of best practice developed for them. > >I see the ability to write cryptic files that are only 3 > lines long and from > >that produce a 50 pages long ANT file, to be king of outside > ANTs goals. > > > >Now providing a hook or something for those who really want > to go that way, > >well I may be convinced of that, but as such we shouldn't be in the > >bussiness of deciding what technologies they should or they > should not use. > >They should be on their own on that. > > thats ludicrous. Imagine if every user of make had to make up > their own > version of automake/imake/autoconf/whatever. There is already too many > choices in that area. Hopefully we will recomend and support > one method but > if peeps want to do it another way then that is also fine. > So, should antidote add to its charter the development of a full fledge XSLT template editor? That will keep them busy for a while :-) No one is saying every user will have to write their own system. I am saying such things should be separate from ANT. ANT should be agnostic about it and jakarta-ant should allow the rules of the "market-place" finally decide what people like or not like to use. As long as ANT provides plugability, there should be no reason for ANT to be in the bussiness of maintaining and/or distributing XSLT, JPYTHON, or something else. Jose Alberto
