> Simeon Fitch wrote: [snip] > > 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 issues. 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. Wolf
