----- Original Message ----- From: "James Duncan Davidson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 20, 2000 23:47 Subject: Re: Did somebody say Shut up and Write? :)
> The problem to be solved is cross platform building and packaging of Java > based projects. That was the original goal -- and is still the clearest > problem to be solved. +1, with 'and deployment' insert in sentence 1. > All other problems that can be solved are tangential to that original > problem case. While it would be nice to use Ant to build c/c++ files -- > actually Configure/Make serve some really good needs here that just don't > happen in the Java world. There's no reason why all of this can't be done > with Ant as currently implemented even, however it's not the original > problem domain. Same with XML/XSLT/Website builds. Possible, but it *is* > important to know what the highest order bits are. +1 One of the great improvements of Ant over the build tools which I used before was in the way it can be extended from within. If you wanted your makefile to do something complex, you'd code it in the makefile to end up with a makeful you were scared to look at, let alone share. Ant, on the other hand positively encourages users to add their own extension tasks, and then , once written, these tasks often submit the tasks back to the ant CVS tree (for lack of a better place). This is where ant's breadth of tasks has come from, especially all the deployment related tasks from sql to the EJB suite. Any split in ant future evolution runs the risk of impoverishing all the alternatives, as some tasks would end up written for one ant descendant or another, and the other ant variants would all be left the poorer. And I dont want that to happen. It won't help my development process, and it won't motivate me to submit new tasks or patches to any of the variants. There are two possible solutions to this problem Firstly, that we don't have a split in the Ant tree, that we do work to resolve the issues, take the best ideas and design patterns from them all and then produce something that is better than any one of its own. That would be nice. Secondly, that we come up with a means of allowing tasks to be re-used in multiple frameworks. That would mean defining the task interface and base implementation such that it wasn't dependent upon any particular framework, and for all the common 'services' which the tasks use -from log() to setting file times is provided via an interface which can by implemented by different 'project service providers'. If it is done right then someone could build an installer application from ant tasks, or a GUI which executes the tasks directly. My ideal solution would be that we do come with a unified design, but that the tasks evolve to become reusable beans of work which can be hosted inside any task execution environment. That way if I want to do something in my own code which talks to j2ee servers or imports SQL statements into a database, I can do with these task beans and snippets of declarative XML, rather than make life hard for myself by rewriting and re-debugging everything . Of course the primarry purpose of the tasks should still be for the cross platform java build tool called Ant. -Steve PS, this morning's bootstrap is failing on my box with :- C:\java\Apps\jakarta-ant\build.xml:288: Failed to copy C:\java\Apps\build\ant\lib\core\jaxp.jar to C:\java\Apps\jakarta-ant\lib\core\jaxp.jar due to C:\java\Apps\jakarta-ant\lib\core\jaxp.jar (Access is denied) java.io.FileNotFoundException: C:\java\Apps\jakarta-ant\lib\core\jaxp.jar (Access is denied) This is probably because I always check out from CVS read only by default, and I can fix it with a quick attrib -r call, but a better solution would be preferred...
