ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "yuxin ruan" <yu...@proofspace.com>
Subject RE: Ant GUI
Date Mon, 30 Oct 2000 17:50:39 GMT
And one more request:
	To flatten a tree of depedent tasks into user defined level.
		Yuxin

-----Original Message-----
From: yuxin ruan [mailto:yuxin@proofspace.com]
Sent: Monday, October 30, 2000 11:41 AM
To: ant-dev@jakarta.apache.org; simeon@fitch.net
Subject: RE: Ant GUI


Hello All:
	From my perspective, the most helpful information that a GUI can provide is
the dependency relationship. Specifically, I want to know given a task, what
are all sub tasks that this one depends upon, and what other higher-level
tasks are depend upon it. The XML does not give a very direct representation
of that. For the attributes of any task, I can type them faster than I can
clicking mouse on a GUI, though some distinctive icons are helpful;-)
	Just my thoughts.
		Yuxin

-----Original Message-----
From: Simeon Fitch [mailto:metasim@yahoo.com]
Sent: Monday, October 30, 2000 11:18 AM
To: ant-dev@jakarta.apache.org
Subject: RE: Ant GUI


>
> Ant's build.xml file is XML. So why not use an XSL
> file and transform the
> build file to HTML ? Your browser can then be used
> to configure Ant for used
> projects.

Interesting idea that should be explored, IMO. A
couple of thoughts on this:

1) Although the use of XSL with XML allows one to
separate presentation from data, such an approach
still structures the user experience more or less in
relationship to the datafile organization. In other
words, the configuration and management of ant builds
through an XSL based UI will be implicitly organized
in the same way as the XML file. This may not be a bad
thing; a directory "explorer" tree maps directly to
the tree structure of a filesystem, which turns out to
be a decent approach in many cases. However, I think
we should have a discussion about the differnet
perspectives that a "standard ant user" might want to
view a software build, maybe even multiple views (a
XSL view and a dependency graph view).

2) The so called "stateless" nature of HTML makes it
difficult to implement dynamic, event driven
processes, a class of application which Ant falls in.
Imagine trying to add a feature in a HTML based app
whereby the status of a build is updated dynamically
on the screen (which would be even cooler with some of
the paralellism features that have been discussed!).
In an app server/servlet container like JRun most of
the browser configuration is essentially setting
properties, which HTML is great at doing. But whenever
you want to display changing information you need to
drop in an applet, or hack in refreshing pages (did I
miss an approach here?). Again, this may be OK,
especially in the short term since an XML-XSL
configuration tool would be easier to implement than a
GUI, but I think ultimately it limits the user
experience (productivity) and long term options for
the UI.

3) This is probably a weak argument, but a browser
based configuration tool implies an HTTP server
somewhere, which seems like a pretty indirect way to
create and manage a build configuration file. However,
I can certainly see the appeal of launching a build
with ant, and then connecting remotely from home to
check on it and re-launch ceratain targets. But this
gets into an architecture discussion of what the role
of Ant is, vs. a GUI, vs. a build monitoring system,
etc. Ant still needs to startup and execute quickly,
and one should ensure that the features are
componentized appropriately. Should build monitoring
be a separate "TODO"?

Simeon


=====
mailto:simeon@fitch.net

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/


Mime
View raw message