ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siberski, Wolf" <>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Wed, 15 Nov 2000 15:15:54 GMT
> Simeon Fitch wrote:
> Only one of several arguments I'm trying to make, and
> I don't think the "cleaner core" argument has been
> strongly posed. I certainly can be swayed by this
> argument (even at the expense of having to write a lot
> more code), but I'd like to hear how having Project,
> Task, Target, etc. implement the Element interface
> results in an ugly or burdensome API (especially if
> they implement it via inheritence from a AntBaseNode
> class or something similar).

As I don't know DOM well enough, I can't comment
on it being too heavyweight. But from a separation 
of concerns point of view it seems doubtful
to bind the Ant object model tightly to its 
external XML representation.
My opinion is that XML is just one way to store
the structure of an Ant project. Others would 
be a database (maybe useful for very large systems)
or hard-coding the build 'file' as Java source
(appropriate when using as an installer).

This is one reason why I wouldn't
like the Ant core classes implementing
a DOM interface. E.g. when using Ant as 
installer, that would force one to 
include DOM into the setup jar without
any need for it.

> I hope I'm not coming across as being rabid on this
> issue; I just want to make sure that the benefits are
> understood from a long term perspective. That being
> said, if the Ant data model ends up /not/ being DOM
> compliant, I will probably have to mirror the data
> model in order to preserve the ability to marshal and
> unmarshal (if you will) the build.xml file in a way
> that preserves comments and Text nodes. 

I see this hierarchy duplication as an advantage,
not as drawback. We could locate the build logic
in the core classes, while leaving interpreting 
and outputting XML, creating the  corresponding 
Ant objects, etc. to the DOM based hierarchy.
Although I admit that this design variant imposes 
additional effort to synchronize both object 
trees, I think it is worth it.
We gain a clear seperation of build logic
issues from externalization/representation

My proposal would be to have this DOM based
hierarchy part of the main Ant source tree,
not of the Antidote part. The command line
version should use the same mechanism
to read the build file and create the
corresponding Ant object tree.


View raw message