> > 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:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
