At 04:09 14/12/00 -0500, you wrote: >Thanks for the lengthy reply. You should really post this mail and some design >docs into CVS.
Probably ;) >If you really want a cure for insomnia, look at the source for >myrmidon and try to figure out what its purpose/intent is. ;-) Even after >reading this post, I am not much closer to understanding your proposal. unfortunately you need to be at least passing familiar with patterns used in Avalon :/ >I may also be a bit backwards in my thinking, but I think most successful >projects (opensource or otherwise) have a clearly stated purpose and direction. agreed. >I think the current version of Ant is a very capable, elegant, and easy to learn >*build* tool. I would like to see Ant remain a *build* tool. IMHO, task-based >execution is what Ant is about and what it should remain consistent with. What the user see will be a clearly defined simple build tool. I actually intend to write a XSLT sheet across the top of it to simplify it even more. The reason being that most of the people I have converter to Ant are web-develoeprs rather than programmers - thus not always comfortabkle with structure of ant. >If you can shoehorn different domains into this model then that is great, but it >seems like you are advocating the generalization of the current build model. Why think small when you can think big? >While this can be a powerful paradigm, it can also dillute the effectiveness of >Ant's original goal, "Ant is a Java based build tool.". Nope - the users don't care what the backend is - it could be written in perl or c and it wouldn't effect the users besides the few who write tasks. The taskwriters job will actually be simplified by clearly deliminating responsibilities. One of the reasons why EJB/Servlet type specs are successful - they incorporate the same patterns (ie Inversion of Control and Seperation of Concerns) but do it at a coarser level. >I also recognize that most projects like this often do not think beyond their >intended design. I believe that you custodians of Ant have decided that it is >time for Ant to break out of its box, and I welcome that. no one else but me and one other has expressed this but I hope there are others out there who share my vision ;) >Ant needs to be more >integration friendly. I would personally like to see: agreed. >1. a stable Project-Target-Task object hierarchy (although these should really >be defined interfaces, not classes). done in mymidon and will soon be done in AntEater >2. an effective design to support the reading *and* writing of these classes. again - both proposals cover this ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
