ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <meta...@yahoo.com>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 14:07:01 GMT

--- Jose  Alberto Fernandez <JFernandez@viquity.com>
wrote:
> > 
> > Editing is the primary reason. And in this
> discussion
> > I don't think we should think of it as an
> "internal
> > representation". That's what we have now. What we
> want
> > is an API. There are probably many other reasons
> > outside of editing that an external app may want
> to
> > manipulate Ant's data model (e.g. implementing
> > parallelism).
> > 
> 
> This is exactly what I think is very very wrong.
> Lets assume
> that you have the ability of editing ANTs internal
> representation
> of the project. Now that means that any validation
> or caching
> that ANT mades to its representation of the project
> it may be
> put at risk of inconsistencies because the GUI
> decided to edit
> something,for example, in the middle of a run (in
> some other thread).

I think there might be a disconnect here in what I'm
proposing, and how you are interpreting it, or at
least a difference in vision. 

1) You keep referring to Ant's "internal
representation" which leads me to believe you invision
them as being separate entities. I'm arguing that we
should be able to take the representation that the GUI
manipulates (not during build runs, but before), and
directly call the "Target.execute()" method to start a
build. During the call of Target.execute(), the Ant
build code has no knowledge of whether the data
structures came from the GUI for directly from the SAX
parser that Ant using in command line mode. 2) I don't
know if the GUI would ever want to modify the DOM
structure *during* runtime, so the GUI would probably
just go into passive mode, reporting status etc.
unless the user wanted to stop the build. However,
there may be some reason for embedded scripts to
modify the DOM, like JavaScript can on an HTML page. I
don't know about that one. 3) Even /if/ the GUI did
modify the DOM structure during build execution, and
the data model was properlly protected, if they share
the same data model then there is not synchronization
issue to deal with; it's the same data model. This is
a big *IF*, as I don't perceive the GUI wanting to do
this.

> This would mean a lot of defensive coding just to
> protect against
> extrange manipulation of the internal
> representation.
> 

No protection necessary. All the And data model
implementer has to do is say in the JavaDoc that the
data model is not thread safe.

> BTW, one of my problem with the current API exposed
> by <script>
> is that is allows people to do things like this. I
> think that is wrong.

Philosophically wrong? Technically wrong? What if a
script section wanted to generate targets dynamically?
I don't know why someone would want to do this, but if
we had a robust data model that didn't preclude this
type of programming(hacking), why limit us now in what
we might decide is a desirable thing down the road. If
a redesign is going to take place, now is the time to
make sure the data model is elegant, robust, and
extensible as practicable. The goal is not to ever
have to go back and change it again. And I'm trying to
argue that supporting some of the DOM semantics in the
Ant datamodel is going to serve us well down the road.

> The point is that
> from your DOM we get an instance of the project use
> it and discard it
> once we have use it. The only permanent
> representation is the GUIs.
> ANT's representation only lives as long as ANTs
> execution.
>

I would argue that it is more like there is one
instance of the Project, and it is Ant that goes away
between builds. Now this isn't really correct as Ant
is just an API as far as the GUI is concerned. What
really goes away is the thread of execution that is
the "build process". a) The GUI starts a new thread in
which the build runs. b) The GUI reports on all the
BuildEvent objects it has registered for. c) The GUI
reenables editing functions once the build thread has
stopped.
 
> This is not all is needed, you probably will need a
> way to catch
> requests from ANT to execute other projects that it
> trys to build
> using <callant> and <ant>. So there should be an API
> for ANT to ask
> for it, that the gui can intercept and look at its
> onw repository of
> DOM in memory subprojects. So that they are
> retrieved from the GUIs
> DOM representation.
> 

As long as sub-builds aren't executed in a forked JVM,
the GUI should get all this information via the
BuildListener interface that it registers.

> But all that can be done without manipulating ANTs
> internal representation.

Again, during a build I don't see manipulation of the
data model as a desired feature.


> This is exactly what the code above does, the
> difference is that
> your datastructures and ANTs are separate. If you
> decide to make big
> changes or ANTs does, as long as the XML and ANTs
> semantics
> remains the same no one is affected by the other
> changes.

What I'm hoping for is the same data structures so
that if "bug changes" are made, they only have to be
made in one place.


> If the datastructures are different, we still need a
> way
> for the GUI to find out what is going on during the
> execution
> of the build, like for doing tracing of the
> execution.

I think the BuildListener and BuildEvent APIs provide
all that is needed.

> 
> So you want the GUI to be able to listen for events
> and being able
> to associate identify which object in its DOM
> representation should
> be affected by the event produced by ANT. I am not
> sure that the
> current Listener API is informative enough.
> 

The current BuildEvent API allows you to get the
current Task, Project, etc. so if Ant and the GUI are
sharing the same API then objects reported by the
BuildEvent will be resolvable in the GUI
automatically.

> The idea I was thinking was to decorate the DOM with
> IDs which are
> stored in a table or something, and have the
> Listener events return
> those IDs as part of the even stream. With this the
> GUI will be able to
> correlate the two representations.
> 

Again, if the BuildEvent is reporting status on
objects that the GUI already has references to, this
is taken care of without the use of IDs.


sim


__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Mime
View raw message