At 12:02 11/12/00 +1100, Conor MacNeill wrote: >One thing which I would like some thought on is the situation where we have >a task which defines an "interface" and for which there may be many >implementations. A current example would be the <ejbjar> task which really >defines an interface into which specific EJB deployment tools can be plugged >in (as nested elements).
Very kewl idea. I would like to see it done in a way similar to how Sockets are abstracted. By doing it this way we make sure that no implementations behind facade offer further services. ie I would hate it if suddenly javac/jikes/jcv/whatever started to become incompatable with each other because the task authors decided to allow extra task specific sub-tags. We could provide a controlled mechanism for extentions/added sub-elements/attributes thou. These would be ignored if task not recognizes them. >Another candidate is the <javac> task itself. The current mess of supporting >many compiler variations is not really nice. I would like to see a mechanism >where different compilers could be plugged in. In fact such a system would >allow the Jikes implementation to be moved out of the core and into the >Jikes project. Naah that would suck. Jikes does not have any java parts in project and when distributed rarely comes with source/whatever. It would be hell for some developers to get jikes to work in an environment like that. >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. agreed. 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 | *-----------------------------------------------------*
