ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Wed, 15 Nov 2000 21:39:27 GMT
I agree with Wolf with respect to the separation between
external representation and ANT's object model.

The ANT core and ANTs object model should be as compact as possible.
DOM, is an external representation which may be useful for a GUI
but it is definetly just bloat for those not requiring navigation
over the DOM tree.

I do not think you can support just parts of DOM, you will need to implement
the navigation primitives, get parent, get siblings, get doc root, get ...
set ..., etc, etc. So at the end you finish with a bunch of extras that ANT
does not need.

I would argue that you should consider ANTs object model as the compiled
representation of the ANT XML. The GUI needs to work on the ANT parse tree
(DOM)
but not on the ANT "bytecodes". When you push the "build" button,
you are telling ANT to compile the external representation into its object
model
and execute it. After that you can throw away the compile if you make
changes
in the source (i.e., DOM tree).

ANT compilation is fast enough as to not being a problem.

Now notice that "compile" means, for me, starting from a SAX stream of parse
events
build ANT's object model. What we need to clean are the API to allow these
event
streams to come from a variety of sources: XML parsed files, DOM trees, and
so forth.

As I said, the other side of this issue is to see if our current event model
is good enough to allow for "tracing" or "debugging" of builds. Can a DOM
listen to
events occurring in the compiled representation? Is there a way to do step
by step
execution? Can I build a listener that allows me to do all these things?
Is anything missing?

I think that we almost have all the parts, we just may need to hop one more
time :-)

Jose Alberto


> -----Original Message-----
> From: Siberski, Wolf [mailto:Wolf.Siberski@tui.de]
> Sent: Wednesday, November 15, 2000 7:16 AM
> To: 'ant-dev@jakarta.apache.org'; 'simeon@fitch.net'
> Subject: RE: Proposed Revolution: AntEater (a proposal for 
> Ant Core 2.0)
> 
> 
> > 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
> 

Mime
View raw message