--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > * The ability for GUI/IDE tools to integrate easily with object model > without reinventing the wheel and writing their own parser (which > antidote was forced to do). > > Two suggested solutions were allowing GUI developers to extend > object model (ie GUITask extends Task) or to have Task as interface > (ie GUITask implements Task). This way the GUI tasks could be W3C > DOM Elements, have property vetoers/listeners etc. >
+1 > * support for numerous frontends - from command line over GUI to servlets > > corollary of the above? +1 (although the goal should be restated as "support embedding via API", just like you can link Java into a separate application). > > * Fully interpreted at runtime. This almost requires some form of > abstraction/proxy that stands in place of tasks till it is > interpreted. This can be hashtables/simple dom-like model/whatever > +1 (definately) > * provide utility classes to aid in building tasks. ie like up-to-date > functionality abstracted > > Need to become more specific here. +1 (see org.apache.tools.ant.gui.acs.ACSFactory) > > * make ant-call a low cost operations so it can certain > optional/template-like operations > > corollary of "fully interpreted at runtime"? +0 (or "ant should be efficient with its resource usage????") > > * allow facilities to build projects from multiple sources. ie CSS+xml > or XSLT+ XML or Velocity+text or database or from inside jars or normal > > build.xmls etc. > > allow the project tree to be built dynamically. +0 (not knowledgeable enough) > > * move to a system that allows docs to be generated - doc snippets > should be included with the tasks they document. > > Which DTD? Which tools for generation? +0 (what does "move to a system" mean? Are we talking Doclet for Ant build file?) > > * allow tasks to be loaded from jars. tasks should be indicated by > either xml file in TSK-INF/taskdefs.xml or manifest file. +1 > > * allow documentation to be stored in .tsk jars > > corollary of the two points above? +1 > > * better scripting/notification support so the hooks are available to > send notifications at certain times. > > Which hooks and where? -1 (requirement is too unclear; need to know what the impact of task developers would be. What are the long term implications?) > > * separate tasks into .tsk jars somehow. (Probably via function - ie > java tasks, file tasks, ejb tasks). > > Decide on categories. +1 (same as above?) > > * make separate build files easy (ala AntFarm) and importing different > projects a breeze +1 (and I add "make the semantics clearly and simply defined") > > * provide support for user defined task configurations - i.e. give > users the ability to specify a default value for attributes (always > use debug="true" in <javac> unless something else has been > specified). > > Three ideas so far: a CSS like language, a <taskconfig> element, > properties following a specific naming scheme. -0 (how does this affect the "simplicity" goal?) > > * support more control over the properties that are going to be passed > to subprojects (modules) +0 (I'd rather see this stated as "provide a consitent, scoped, proprities model"). > > * Ask for a new CVS module for Ant tasks. > > We need to define rules for this to work - maybe the rules proposed > for the commons project could give us a start. +0 (not enough knowledge to judge. Where does this diverge from the existing CVS/Version Control task(s)). > > * It should be possible to modify details of the actual build (e.g. > classpath, > used compiler) without the need to change the build specification. > > Do build.compiler and build.sysclasspath cover everything or do we > need to add more stuff like this? +1 (does this fall in with "allowing default values"?) > > * Task to prompt for user input. > > Does affect core as we need a means to request input from the Frontend. +1 > > * Add cvs login feature. > > Requires handling of user input. +1 > > * Easier installation process. GUI - maybe webstart from the homepage. > > This includes asking the user whether he wants to use optional tasks > and downloads the required libs. Automatic upgrades and so on. > > Self-extracting jar installer: java -jar jakarta-ant-1.3-bin.jar. > Prompts for destination directory, extracts archive, fixes all > text files with fixCRLF task; on UNIX, makes scripts executable. > Could also modify ant scripts with the location of ANT_HOME. +1 > > * Logo for Ant. +0 > > * detach Ant from System.err/.in/.out. +1 > > Beware of problems with spawned processes. > > * better subproject handling > > Whatever that means in detail. +1 (see above on "clear and simple semantics") > > * build files should be declarative in nature > +0 (feature or design goal?) ===== Mustard Seed Software http://www.mustardseedsoftware.com mailto:[EMAIL PROTECTED] fax:1.309.424.4982 __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
