ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [Proposal] myrmidon
Date Tue, 05 Dec 2000 16:11:07 GMT
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

> Currently there is 4 different parts to the proposal. The launcher,
> the converter api, the tasklet api and the project api. (Eventually
> there will also be a data-type registry aswell).

Think there should be one for data types, yes.

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

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

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

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

They don't?

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

> Currently the system is 1.2 only - however I don't see this as an
> issue.  BSDI has recently got a 1.2 JDK which I assume means the
> FreeBSD jdk is near to being out of beta ??? Even if it is not - it
> will be out of beta by the time that Ant2 comes around.

View raw message