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 Fri, 19 Jan 2001 09:00:23 GMT
bodewig     01/01/19 01:00:23

  Added:       docs/ant2 requested-features.txt
  Log:
  Brainstormed list of requested features for Ant2. This is far from
  being a functional-requirements document, just a start.
  
  Most of it taken from an email by Peter Donald
  <http://marc.theaimsgroup.com/?l=ant-dev&m=97721709607672&w=2> and my
  response to it
  <http://marc.theaimsgroup.com/?l=ant-dev&m=97722025813209&w=2>. Added
  some additional stuff to the end of the controversial section.
  
  Revision  Changes    Path
  1.1                  jakarta-ant/docs/ant2/requested-features.txt
  
  Index: requested-features.txt
  ===================================================================
  Brainstormed and unordered list of requested features of Ant2:
  
  * namespace support so different concerns can occupy different namespaces
    from ant (thus SAX2/JAXP1.1)
  
  * Java2
  
  * 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.
  
  * 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
  
  * make ant-call a low cost operations so it can certain
    optional/template-like operations
  
  * 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
  
  * 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)
  
  * good event model to integrate well with IDE/GUI/whatever
  
  * better scripting/notification support so the hooks are available to
    send notifications at certain times.
  
  * allow all datatypes to be defined anywhere
  
  * 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
    java tasks, file tasks, ejb tasks).
  
  * unify multiple similar tasks to use similar forms (ie all the javacc
    type tools)
  
  * support for numerous frontends - from command line over GUI to servlets
  
  * make properties fully dynamic, i.e. allow their value to be reassigned
  
  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
  
  * unify the namespace of all data types (ie properties + filesets +
    patternset + filtersets).
  
  * provide datatypes through property tag and remove need for seperate free
    standing entities. ie
    <property name="foo">
      <fileset dir="blah">
       <include name="*/**.java" />
      </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
  
  * 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
    partially solve the JARs in CVS thing.
  
  * provide support for CJAN
  
  * provide support for non-hardwired (ie loadable) converters.
  
  * provide support for non-hardwired (ie loadable) datatypes.
  
  * 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 ...
  
  * 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.
  
  

Mime
View raw message