ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bode...@apache.org
Subject cvs commit: jakarta-ant/docs/ant2 requested-features.txt
Date Wed, 07 Mar 2001 12:35:01 GMT
bodewig     01/03/07 04:35:00

  Modified:    docs/ant2 requested-features.txt
  Log:
  Restructured requested-features.txt and added some comments. No new content.
  
  Revision  Changes    Path
  1.4       +98 -55    jakarta-ant/docs/ant2/requested-features.txt
  
  Index: requested-features.txt
  ===================================================================
  RCS file: /home/cvs/jakarta-ant/docs/ant2/requested-features.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- requested-features.txt	2001/03/01 09:18:30	1.3
  +++ requested-features.txt	2001/03/07 12:34:59	1.4
  @@ -1,16 +1,74 @@
  -Brainstormed and unordered list of requested features of Ant2:
  +List of requirements for Ant2 split into categories. 
   
  +If you disagree with the category something has been put into, speak
  +up.
  +
  +I. Things that don't affect the core but are requests for new tasks or
  +enhancements of existing tasks.
  +======================================================================
  +
  +* make usage of particular filters/filtersets explicit in copy tasks
  +
  +* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
  +
  +* unify multiple similar tasks to use similar forms (ie all the javacc
  +  type tools)
  +
  +II. Abstract goals that need to be abstract until we get into design
  +decisions.
  +======================================================================
  +
  +* remove magic properties if at all humanly possible
  +
  +* remove as much dependency on native scripts as possible.
  +
  +* clean object model (ie Project/Target/Task)
  +
  +* good event model to integrate well with IDE/GUI/whatever
  +
  +* use a consistent naming scheme for attributes across all tasks
  +
  +* keep build file syntax as compatible to Ant1 as possible -
  +  i.e. don't break something just because we can.
  +
  +* keep the interface for Tasks as similar to the one of Ant1 as
  +  possible - i.e. don't break something just because we can.
  +
  +III. Things that are simple, easy to implement, where we expect the
  +committers to agree
  +======================================================================
  +
   * namespace support so different concerns can occupy different namespaces
     from ant (thus SAX2/JAXP1.1)
   
   * Java2
   
  +* remove all deprecated methods, attributes, tasks
  +
  +* allow all datatypes to be defined anywhere - i.e. as children of
  +  project as well as of target.
  +
  +* make properties fully dynamic, i.e. allow their value to be reassigned
  +
  +* unify the namespace of all data types (ie properties + filesets +
  +  patternset + filtersets).
  +
  +IV. Things we probably agree upon but need to discuss the details or
  +decide between several possible options.
  +======================================================================
  +
   * 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.
  +  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
  @@ -19,58 +77,57 @@
   * 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 database or from inside jars or normal build.xmls
     etc.
   
  -* remove magic properties if at all humanly possible
  -
  -* make all tasks consistent and remove all deprecated methods
  -
   * move to a system that allows docs to be generated - doc snippets
     should be included with the tasks they document.
   
  -* allow documentation to be stored in .tsk jars
  +  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.
  -
  -* remove as much dependency on native scripts as possible.
   
  -* clean object model (ie Project/Target/Task)
  +* allow documentation to be stored in .tsk jars
   
  -* good event model to integrate well with IDE/GUI/whatever
  +  corollary of the two points above?
   
   * better scripting/notification support so the hooks are available to
     send notifications at certain times.
   
  -* allow all datatypes to be defined anywhere
  +  Which hooks and where?
   
  -* make usage of particular filters/filtersets explicit in copy tasks
  -
  -* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
  -
  -* seperate tasks into .tsk jars somehow. (Probably via function - ie
  +* separate tasks into .tsk jars somehow. (Probably via function - ie
     java tasks, file tasks, ejb tasks).
   
  -* unify multiple similar tasks to use similar forms (ie all the javacc
  -  type tools)
  +  Decide on categories.
   
  -* support for numerous frontends - from command line over GUI to servlets
  +* make separate build files easy (ala AntFarm) and importing different
  +  projects a breeze
   
  -* make properties fully dynamic, i.e. allow their value to be reassigned
  +* 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). 
   
  -Now there is a bunch of "controvertial" points. By controvertial I mean not
  -everyone agrees or else there has not been enough comments to to judge
  -reception
  +  Three ideas so far: a CSS like language, a <taskconfig> element,
  +  properties following a specific naming scheme.
   
  -* unify the namespace of all data types (ie properties + filesets +
  -  patternset + filtersets).
  +* support more control over the properties that are going to be passed
  +  to subprojects (modules)
  +
  +V. Things we probably don't agree on. 
  +======================================================================
   
  -* provide datatypes through property tag and remove need for seperate free
  +* provide datatypes through property tag and remove need for separate free
     standing entities. ie
     <property name="foo">
       <fileset dir="blah">
  @@ -78,15 +135,10 @@
       </fileset>
     </property>
   
  -
   * make it possible to reuse taskengine for other things. ie
  -  Installshield type app, my cron-server and other task based
  -  operations. Currently no committer other than me has expressed
  -  positive or negative thoughts about this
  +  Installshield type app, Peter's cron-server and other task based
  +  operations. 
   
  -* make separate build files easy (ala AntFarm) and importing different
  -  projects a breeze
  -
   * create the concept of workspace so that projects can be built in a
     DAG and thus enable projects like catalina/tomcat to have an easy
     build process. It also helps CJAN to a lesser degree and would
  @@ -94,31 +146,22 @@
   
   * provide support for CJAN
   
  +  In what way?
  +
   * provide support for non-hardwired (ie loadable) converters.
   
  -* provide support for non-hardwired (ie loadable) datatypes.
  +  What is a converter? Is this an implementation detail?
   
   * generate docs by anakia/XSLT
   
  -* 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). Could be a CSS like language, could be a <taskconfig>
  -  element ...
  +  Corollary of "move to a system that allows docs to be generated"?
   
  -* support more control over the properties that are going to be passed
  -  to subprojects (modules)
  -
  -* keep build file syntax as compatible to Ant1 as possible -
  -  i.e. don't break something just because we can.
  -
  -* keep the interface for Tasks as similar to the one of Ant1 as
  -  possible - i.e. don't break something just because we can.
  -
   * tasks provide some way to identify their attributes from the
  -  outside. Possible solutions include a special method like
  -  getProperties(), an external describing file shipping with the task
  -  class or special javadoc comments parsed by a custom doclet.
  +  outside. 
  +
  +  Possible solutions include a special method like getProperties(), an
  +  external describing file shipping with the task class or special
  +  javadoc comments parsed by a custom doclet.
   
   * allow build file writers to modify logging (verbosity for example)
     on a target by target or task by task basis.
  
  
  

Mime
View raw message