----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 22, 2001 2:30 AM Subject: [VOTE] vote on general direction, details will be discussed later
> 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). +1, but I am -1 on the solutions :-) > > 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 +1 > > 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 +1 > > * provide utility classes to aid in building tasks. ie like up-to-date > functionality abstracted > > Need to become more specific here. +1 - exec and execjava there already. Probably need zip/jar capability too. Also move copy code out of project. > > * make ant-call a low cost operations so it can certain > optional/template-like operations > > corollary of "fully interpreted at runtime"? +1 in general but not sure what is meant by low-cost > > * 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. +1 > > * move to a system that allows docs to be generated - doc snippets > should be included with the tasks they document. +1 > > 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. > +1 > * allow documentation to be stored in .tsk jars +1 > > 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? Exactly. +1 in general but I would like to see specifics. > > * separate tasks into .tsk jars somehow. (Probably via function - ie > java tasks, file tasks, ejb tasks). > > Decide on categories. -1 - why? I'd probably go for core.task and then the various optional tasks in categories, say ejb.tsk > > * make separate build files easy (ala AntFarm) and importing different > projects a breeze +1 > > * 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). > +1 > 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) +1 > > * 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. > -1 - I think this can be done later. I'd like to get the task loading in place first and then think about splitting. > * 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 - Too vague for me. There is a lot of control already possible. > > * 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 - can be done by manipulating the .cvspass file directly I believe. > > * 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 but I would add that installation without the instaler should remain possible as it is today. > > * Logo for Ant. +1 > > * detach Ant from System.err/.in/.out. > > Beware of problems with spawned processes. +1 > > * better subproject handling > > Whatever that means in detail. -1 without detail. > > * build files should be declarative in nature > +1 if we define declarative :-)
