ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Wed, 21 Mar 2001 23:27:04 GMT
+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               |
*-----------------------------------------------------*


Mime
View raw message