At 02:32 11/12/00 +1300, Mariusz Nowostawski wrote: > >javac - java compiler > (classic, modern, jikes, others) > >javacc - java compiler compiler (parser generator) > (metamata, antlr, sablecc, others) >jidl - idl stubs/skeletons generator > (java2 jidl, many others in java and native) >ejbjar - enterprise beans packager (with configuration) > (weblogic, ias, jboss, many others)
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. With respect to the ejbjar* and idl* type tasks I think there is a similar case. Last time I checked these sort of things were container specific and thus not really easy to switch between. However it would be good for them to have similar form and perhaps inherit from a base class ? >> In summary, I think there are cases where it would be nice to define a >> common "interface" for a task and allow different implementations for this >> task. I don't want to lose sight of that unified approach because the >> optional tasks are scattered over the net. > >But should those "interfaces" being kept in ANT core, or should they be >kept in seperate, optional tasks repository? For javac, it should be kept >in the core, but what about others? There is not that many of them, at the >moment which needs to have unified "interface", so maybe that should be >part of the core, and then, all the optional tasks can be scattered over >the places, and there would be no need for a repository of optional tasks? >But it puts some additional work on jakarta-ant commiters. 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. Other examples may be difference between FreeBSD and Linux distributions. I use Linux and very commonly go through hell trying to get all versions matching between RPMs of required tools at required version. Sometimes it is just impossible to do and you have to hand-install stuff. One of my friends runs FreeBSD and as soon as they need something they know they can with a few commands update everything. I hae heard that similar conditions exist for Debian. 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. The number of patched elisp files I have that were abandoned by the original authours is large. If the www.emacs.org group ever get off the ground then they may get updated but until then no one else will see my mods ;/ - I don't want to see the same thing happen with ant. 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 | *-----------------------------------------------------*
