ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz Nowostawski <>
Subject RE: [PROPOSAL] Optional Tasks
Date Mon, 11 Dec 2000 02:46:54 GMT
On Mon, 11 Dec 2000, Peter Donald wrote:

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

True, but I still think, it would be better to have smaller
number of highly parametrized tasks, than many simple, in 
many cases repeating the same attributes and parameters
tasks with task-per-tool model. If I am a developer, who needs task
supporting tool A, which is an EJB container, compiler compiler or jidl
compiler, I just go the the proper section of ANT docs, about jidl
compilers, check my tool is suported there, and how or where to get
optional task jar for for jidl task to support apropriate tool.
Otherwise, we not only risk duplicating code for tasks (which as you said
could be solved by base class or whatever) but also risk repeating
documentation, and making it hard for users to use and manage it all.

I fully agree, that tool specific things are always different, but jidl
always takes the .idl files and generate stubs and skeletons, so, it
depends where we would like to put the granularity - on the task-logic, or
on the tool-implementation?   To me puting on the task-logic would be
nicer, and promote reuse of: base class, helper classes, documentation,
task syntax and semantics.  It is true, javacc task for metamata cannot be
as easily swapped for antlr, as jikes and javac for javac, nevertheless,
javacc always do the same thing: takes grammar and generates parser, and
logically it should be always the same, parametrized task. If one
asks: 'does ant supports parser generators' we say: yes, use javacc task.
if one asks: 'does ant supports tool A which is idl compiler' we
say: check idl compilers section.   Otherwise we always need to now the
tool, and always have to point to a particular ant task for info.

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

Sure. I support central repository as well, but, I think, task
contributors, at least, now, and for comming future, could help by direct
supporting their own tasks, writting docs, etc. True, it can be done in a
'send-patch-we-will-do-it' model, but it takes time, and it puts
additional pressure on ant commiters. Optional tasks are not part of ANT
core, and could be managed by their contributors - sure, ant commiters
could help, could take care of abandoned tasks, and coordinate all the
optional task business, but giving more direct control on optional tasks
to ppl would only help, I think. It seems to me simpler, to keep my own
tasks repo locally, patch it, play with it, and commit it, instead of
keep my own tasks repo locally, patch it, play with it, checkout latest
ANT, prepare patch, send the patch, wait, checkout applied patch, merge
the differences, write docs, prepare the patch, send the patch, wait,
checkout patched docs, merge the differences, repeat the above loop every
now and than when external project evolves.


View raw message