ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: [PROPOSAL] Optional Tasks
Date Mon, 11 Dec 2000 01:18:23 GMT
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

>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.



| "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               |

View raw message