ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: [PROPOSAL] Optional Tasks
Date Mon, 11 Dec 2000 01:02:09 GMT
> -----Original Message-----
> From: Jon Stevens []
> Sent: Monday, 11 December 2000 8:15
> To:
> Subject: [PROPOSAL] Optional Tasks
> I'm still not sure what version of Ant this should apply to, but lets get
> the proposal written before I spend a whole bunch more time justifying
> myself for my reasons. I see a lot of people still not "getting it" so I
> hope to have a proposal to clarify things for people.
> Here are the rules to the proposal:
> -----------------------------------------------------------------
> The definition of a "core" task is a task that Ant really cannot live
> without. This would be similar to taglibs that are part of the core JSP
> specification.
> The definition of an "optional" task is a task that really should be
> packaged with the product it serves.
> However, there are cases where this is not feasible. Therefore, we will
> provide a separate CVS repository and mailing lists that serve as
> a storage
> and support area for tasks that cannot be bundled with the original
> products. Such as a perforce task. This would be similar to the taglibs
> Jakarta Project.

I am cool with this idea. Maybe we can call the project "antlibs" :-)

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

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.

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.


View raw message