On Tue, 9 Jul 2002 [EMAIL PROTECTED] wrote: > > Not sure I understand what you want. Changing the <project> element name > > in build.xml to use a different name you feel is more apropriate ? > > Are you kidding ? > No, I'm saying we need to look at what things are used for and name them > appropriately. <project> has very little to do with project details, and > more to do with <build> details.
So your proposal is to rename <project> to <build>, add more procedural support and make it more scriptable ? > > A number of people ( usually those who -1 the adding of scripting > > elements) believe ant should be more 'descriptive', and not > > procedural. That's why it's called <project> - it is intended to > > describe the project, including how to build various components. > But what it does *NOW* has nothing to do with a project. Are you saying > there should be one file to describe project information like the cvs > repository, sub projects etc and that same file should contain all the > build processes? The ant file can contain any information for which there is a datatype or task. There are projects who have <cvs> tags inside, or who have informations about packages that needs to be downloaded ( tomcat for example ). The tasks that we have are moslty based on what people asked for and contributed - <cvs> is one of the oldest tasks, it has been in ant before 1.0 ( I added it exactly because I wanted the build file to describe how different sources are retrieved ). As a matter of fact, the <get> task was originally used to download binaries we needed to build tomcat. True, most people only want to describe how to build the project - and I see nothing wrong with it. But claiming that ant can only be used for that is pretty wrong. > > Of course, the biggest focus is on describing how to build various > > targets - that's what people need the most. I agree we should add > > more 'descriptive'/higher level data types under <project>, maybe > > what gump uses. > Now you've gotta be kidding. Keep all the project info and all the build > processes in one file? Not sure what you mean by 'build processes'. I agree that logic and programming should go out of the build.xml and be done in java. build.xml was designed to support a 'descriptive' model. It can and is used in a procedural mode, but beeing able to keep all the project info and descriptions is certainly one thing ant can do easily, if it is an itch. Many build.xml files are a mess, and I think most of that is due to use of ant as a script language instead of beeing more descriptive and doing the logic in java and using higher level tasks. > > And what's wrong with a gradual process ? Especially for important > things > > I think we should take all the time it is needed. If something is > obvious > > and all commiters are +1, it'll probably get added fast. > Nothing's wrong with a gradual process, as long as it has a well defined > goal. This hasn't been the case with Ant 1 and Ant 2. I can't remember the > announcement being made that the Ant 2 proposals were being subsumed into > Ant 1 and all efforts should go there. There is no Ant2 AFAIK. There are some proposals, with different names - but I don't remember any vote on a ant2 release. Ant1.6 is the next release, and as far as I know all the efforts should go there. And the goals are still listed and I don't remember any vote to change them. > > If there are doubts - then we should spend more time finding a better > > solution. > I'd be happy if there was a clear committed path forward. It seems that > some committers are interested in Ant 2, and others are keeping the status > quo. But where is the common direction? The path is the same as allways - we just have a vote on a release, the main branch is open, and until a proposal gets voted as the next release of ant, the direction is forward. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
