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 02:05:27 GMT
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

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



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