Conor - Thanks for documenting your design of Mutant. I've had a quick read through it several days ago and my mind has been churning on some things triggered by what you've said there.
Cool.
One of the challenges I face when developing Ant build systems is the fact
that it is tough to support large projects with 1.x. Reusing build file
pieces is difficult with entity references, and its tricky to get <ant> just
right to control things and get properties passed down and inherited
properly.
I agree. I think today in Ant1 there is a lot of copy and paste build file production. That, of course, violates the DRY principle expounded by the Pragmatic programmers.
Anyway, you mention polymorphic types for passing to tasks, which Ant 1.5 has to some extent as well.
I would say that Ant 1.5 supports dynamic elements rather than polymorphism.
Does the object-oriented nature of this include being able to "extend" tasks or projects? I'm thinking at the API level now, not the XML representation.
You say "extend tasks". I may misunderstand you there and perhaps you mean targets. It has always been possible to extend tasks at the API level :-). In fact this will probably be a little harder in Mutant due to classloader separation. Mutant does allow one library to declare that it extends another and this would allow its tasks to extend those in the other library.
As for projects, Mutant doesn't have the concept of project inheritance as such. It supports project reuse in two ways. The use of <include> is a simple way to extend projects. It is similar to the entity mechanism required by Ant1. OTOH, the <ref> mechanism supports composition of projects. The referenced projects may be controlled by the outer build and its targets and properties used. The use of antcall in Mutant should be less expensive than in Ant1 since Mutant does not reparse the XML, nor create tasks that it isn't going to use. I haven't done any tests on Mutant performance so far, however.
Peter has mentioned templating, (they used to be called macros). They are potentially interesting and I have considered their use in Mutant but I'm not sure I want to develop YAML (Yet another macro language). I'll leave that till later, I think.
As for a more object-oriented approach to project reuse - I'm not sure yet. I'd like to see how the project reference concept pans out.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
