+1 on everything but ---- * better scripting/notification support so the hooks are available to send notifications at certain times. ----
Which I would probably -1 unless there was a implementation that was non-intrusive to core. If this was well thought out and wrappers were built then this becomes +1 ... At 05:30 21/3/01 +0100, Stefan Bodewig wrote: >A vote here should only indicate whether you agree with the goal >itself, not with any of the suggested solutions (if there is one). > >* 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. > >* support for numerous frontends - from command line over GUI to servlets > > corollary of the above? > >* 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 > >* provide utility classes to aid in building tasks. ie like up-to-date > functionality abstracted > > Need to become more specific here. > >* make ant-call a low cost operations so it can certain > optional/template-like operations > > corollary of "fully interpreted at runtime"? > >* 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. > >* 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? > >* allow tasks to be loaded from jars. tasks should be indicated by > either xml file in TSK-INF/taskdefs.xml or manifest file. > >* allow documentation to be stored in .tsk jars > > corollary of the two points above? > >* better scripting/notification support so the hooks are available to > send notifications at certain times. > > Which hooks and where? > >* separate tasks into .tsk jars somehow. (Probably via function - ie > java tasks, file tasks, ejb tasks). > > Decide on categories. > >* make separate build files easy (ala AntFarm) and importing different > projects a breeze > >* 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. > >* support more control over the properties that are going to be passed > to subprojects (modules) > >* 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. > >* 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? > >* Task to prompt for user input. > > Does affect core as we need a means to request input from the Frontend. > >* Add cvs login feature. > > Requires handling of user input. > >* 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. > >* Logo for Ant. > >* detach Ant from System.err/.in/.out. > > Beware of problems with spawned processes. > >* better subproject handling > > Whatever that means in detail. > >* build files should be declarative in nature > > Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
