On Mon, 11 Dec 2000, Peter Donald wrote: > I am not sure that all of these should be hidden behind a facade. It makes > sense because a developer can easily swap between jikes, javac or other > compilers. > > However javacc type tasks are not something the developer can switch > between easily. It may make sense for them all to have similar form and > perhaps inherit from a base class but a developer is unlikely to switch > parser generators that willy nilly - and switching would require other > changes in their code.
True, but I still think, it would be better to have smaller number of highly parametrized tasks, than many simple, in many cases repeating the same attributes and parameters tasks with task-per-tool model. If I am a developer, who needs task supporting tool A, which is an EJB container, compiler compiler or jidl compiler, I just go the the proper section of ANT docs, about jidl compilers, check my tool is suported there, and how or where to get optional task jar for for jidl task to support apropriate tool. Otherwise, we not only risk duplicating code for tasks (which as you said could be solved by base class or whatever) but also risk repeating documentation, and making it hard for users to use and manage it all. I fully agree, that tool specific things are always different, but jidl always takes the .idl files and generate stubs and skeletons, so, it depends where we would like to put the granularity - on the task-logic, or on the tool-implementation? To me puting on the task-logic would be nicer, and promote reuse of: base class, helper classes, documentation, task syntax and semantics. It is true, javacc task for metamata cannot be as easily swapped for antlr, as jikes and javac for javac, nevertheless, javacc always do the same thing: takes grammar and generates parser, and logically it should be always the same, parametrized task. If one asks: 'does ant supports parser generators' we say: yes, use javacc task. if one asks: 'does ant supports tool A which is idl compiler' we say: check idl compilers section. Otherwise we always need to now the tool, and always have to point to a particular ant task for info. > I know my opinions are probably different from most but ... I have > experienced all sorts of pain when there was no centralized repository. If > any of you have ever tried to get mixed version of elisp scripts to work > then you porobably know what I mean. > > [...] > > I agree that it may place a bit of extra work on ant-dev but if we place > them in a contrib place and effectively say unsupported then it should be > sweet. Ant-dev will only have to maintain them when they break the contract > between tasks and container (and perhaps other obvious errors). The "work" > done by task is maintained by outsiders who can send patches to > ant-lib/ant-contrib. This way when an outsider abandons a task - or > continues to use the task at a lower version of ant it still can be adopted > by someone else. Sure. I support central repository as well, but, I think, task contributors, at least, now, and for comming future, could help by direct supporting their own tasks, writting docs, etc. True, it can be done in a 'send-patch-we-will-do-it' model, but it takes time, and it puts additional pressure on ant commiters. Optional tasks are not part of ANT core, and could be managed by their contributors - sure, ant commiters could help, could take care of abandoned tasks, and coordinate all the optional task business, but giving more direct control on optional tasks to ppl would only help, I think. It seems to me simpler, to keep my own tasks repo locally, patch it, play with it, and commit it, instead of keep my own tasks repo locally, patch it, play with it, checkout latest ANT, prepare patch, send the patch, wait, checkout applied patch, merge the differences, write docs, prepare the patch, send the patch, wait, checkout patched docs, merge the differences, repeat the above loop every now and than when external project evolves. regards Mariusz
