ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject [VOTE] vote on general direction, details will be discussed later
Date Wed, 21 Mar 2001 16:30:50 GMT
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


Mime
View raw message