ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Proposal] myrmidon
Date Wed, 06 Dec 2000 06:17:03 GMT
At 05:11  5/12/00 +0100, you wrote:
>Peter Donald <> wrote:
>> Anyway I would like to put in for consideration myrmidon. 
>Some first comments - I don't really have the time to delve into
>Avalon ATM and every time I try to see some details I end up with some
>classes from Avalon - so I guess I'll have to pick up the Avalon
>sources sooner or later 8-).
>Being so tightly integrated with Avalon has both, pros and cons. The
>learning curve for new developers will be a lot steeper (so much for
>the cons), on the other hand I'm impressed by the amount of
>functionality of Avalon that can be reused - why reinventing the

yep - thats the one real negative that I see. However hopefully if we can
seperate Avalon from Ant enough it will only be us Project/TaskletEngine
guys that have to deal with it ;)

>> The converter api is basically a registry and a set of basic
>> converters.
>I am not sure that much of flexibility is actually needed.
>> The tasklet api is the API that most people will use and consist of
>> two parts, engine and tasklets.
>Something I don't actually like - and maybe I'm not reading the code
>correctly - is that the task(let) itself has to deal with property
>resolutions. Calling TaskletContext.resolveValue inside the Tasklet
>(see Property for example) means we'll have to rely on the Tasklet
>writer to do the right thing. I'd prefer to see this happen in a
>central place - DefaultTaskletConfigurer?

Yep in 99% of the time DefaultTaskletConfigurer will handle resolution of
values. The one exception is when the tasklet implements configurable. In
this case the task will be 100% responsible for interpreting all the
values. This was done so that *tricky* stuff could be done (like
if/then/else/switch/other) without interference. 

>> The project API manages Targets and Projects and is responsible for
>> building the projects.
>Two minor details I wanted to note: (1) Currently you can specify
>both, if and unless attributes to Target, any reason why you've
>restricted that? (2) I've proposed to perform ${} expansions in the
>attributes of project and target as well, maybe you should move the
>resolution of properties out of TaskletContext into a class of its own
>- or maybe use project's context which is a TaskletContext.

right - I am not sure I like ${} resolution in if/unless attributes thout
it could be done. Resolving properties there seems like like it is entering
the dangerous complexity ground. Considering that ant-call is now a low
cost effect we could use equivelent functionality from that without unduly
increasing complexity.

>> By 1. It is meant that the developer of tasks never has to worry
>> about evaulating values and there is no inconsistencies.
>Oops, so I must be misreading the current Property tasklet, please
>educate me 8-).

see above ;)

>> Currently there is some things that will not evaluate ${} inside it
>> (ie includes in filesets)
>They don't?

they didn't when I forked not sure about now ;)

>> The tasks and converters for the job will be loaded from
>> proposal/myrmidon/dist/lib/core.tsk. You will notice that there is
>> extremely simple meta-data in "TASK-LIB/*.properties" of core.tsk.
>Make that an XML file, pleeeeease ...

The converter one will definetly got to xml - but is there any need for
changing to an xml file ?

>> Future things to do include [...] caching of reflection data (my god
>> reflection is slooooooow)
>I think IntrospectionHelper has some merits here, we don't need to
>drop the old code base completely 8-).

I agree ;) I originally rewrote it because employers didn't want to credit
Apache - but now that that job is done ... ;)

>> For those of you wandering what the name means it comes from an
>> ancient Greek myth. A group of ants were transformed into
>> warriors. The warriors were of course dedicated and onward marching
>> - and strike fear into opposition.
>Nice name, though there seems to be some Mac software and an obscure
>band with that name. 

very little mythological names aren't some form of software somewhere. We
are in the midst of trying to find a mythological name for an Application
Server and they are all taken ;/

>I like <>,
>especially "executes orders unquestioningly" - this is what you'd
>expect from a build tool, isn't it.

yep ;)



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