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 Thu, 29 Mar 2001 08:25:35 GMT
bodewig     01/03/29 00:25:35

  Modified:    docs/ant2 requested-features.txt
  Log:
  results of the first voting stage
  
  Revision  Changes    Path
  1.55      +158 -7    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.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- requested-features.txt	2001/03/26 07:56:45	1.54
  +++ requested-features.txt	2001/03/29 08:25:33	1.55
  @@ -1,115 +1,194 @@
  -List of requirements for Ant2 split into categories. 
  +Status:
  +=======
   
  -If you disagree with the category something has been put into, speak
  -up.
  +The items in the first four categories have been voted upon with votes
  +coming from Peter Donald, Simeon Fitch, Conor MacNeill, Nico Seessle,
  +Stefan Bodewig and Glenn McAllister. The items that didn't get the
  +required number of positive votes - or received negative votes - will
  +need to be discussed in detail.
   
  +The items in category five are under discussion right now on the
  +ant-dev mailing list.
  +
   I. Things that don't affect the core but are requests for new tasks or
   enhancements of existing tasks.
   ======================================================================
   
  +[ACCEPTED] for a task doesn't mean that task will be core tasks (or
  +even be supplied by a voter), just that having them (as optional
  +tasks) would be acceptable.
  +
   * Add a new datatype filterset to group token-filters 
   
  +  [ACCEPTED]
  +
   * make usage of particular filters/filtersets explicit in copy tasks
   
  +  [ACCEPTED]
  +
   * make facade tasks for things like javac (JikesImpl, ModernImpl etc)
   
     One candidate is jar with implementations for fastjar
     for example.
   
  +  [ACCEPTED]
  +
   * unify multiple similar tasks to use similar forms (ie all the javacc
     type tools)
   
  +  [ACCEPTED]
  +
   * Obfuscating task
   
  +  [ACCEPTED]
  +
   * Add an <ant> task that will find build files according to a fileset
     and invokes a common target in them.
   
     <anton>?
   
  +  [will need more discussion because of votes by Peter Donald and
  +                                                 Stefan Bodewig]
  +
   * Add a JavaApply task that executes a given class with files from a
     fileset as arguments - similar to <apply>.
   
  +  [will need more discussion because of votes by Peter Donald and
  +                                                 Stefan Bodewig]
  +
   * Include some more sophisticated loggers with the Ant distribution -
     especially for sending emails. Make the existing one more flexible
     (stylesheet used by XmlLogger).
   
     Could be part of the same module tasks would be developed in?
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * make the default logger's output clear, informative, and terse.
   
     Actually, this is a little bit abstract, but doesn't apply to the
     core either.
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * Better docs.
   
     More examples. Tutorials, beginner documents, reference sheets for
     tasks, printable version.
   
  +  [ACCEPTED]
  +
   * RPM task.
   
  +  [ACCEPTED]
  +
   * add an attribute to <property> to read in an entire file as the
     value of a property.
   
  +  [will need more discussion because of vote by Peter Donald]
  +
   * Task for splitting files (head/tail/split like functionality).
   
  +  [ACCEPTED]
  +
   * Task to create XMI from Java.
   
  +  [ACCEPTED]
  +
   * socksified networking tasks, SSH tasks.
   
  +  [Peter Donald expressed some legal concerns that might be overcome, 
  +                depending on the implementation]
  +
   * a reachable task that works much like available for network URLs.
   
  +  [ACCEPTED]
  +
   * make PATH handling consistent. Every task that has a PATH attribute
     must also accept references to PATHs.
   
  +  [will need more discussion because of vote by Stefan Bodewig]
  +
   * Task to extract classes from a JAR file that a given class depends
     on.
   
     Based on <depend> or IBM's JAX for example.
   
  +  [ACCEPTED]
  +
   * Unify <available> and <uptodate> into a more general <condition>
     task, support AND/OR of several tests here.
   
  -* Integration of the depends task and javac tasks
  +  [will need more discussion because of vote by Peter Donald]
   
   * jsp-compilation task
   
     Sounds like a candidate for a facade task.
   
  +  [ACCEPTED]
  +
   * URL-spider task that checks links for missing content or server errors
   
  +  [ACCEPTED]
  +
   II. Abstract goals that need to be abstract until we get into design
   decisions.
   ======================================================================
   
  +During discussion it became obvious, that some things from this list
  +are goals for Ant and some should be guidelines for developers,
  +therefore there are two flavors, [ACCEPTED] and [ACCEPTED AS GUIDELINE].
  +
   * Provide a clear mission statement for Ant.
   
  +  [ACCEPTED]
  +
   * Main goals: Simplicity, Understandability, Extensibility
   
  -  Simple and understandable for the target audience - developers,
  -  build-engineers ...
  +  [ACCEPTED]
   
   * remove magic properties if at all humanly possible
   
  +  [ACCEPTED]
  +
   * remove as much dependency on native scripts as possible.
   
  +  [ACCEPTED]
  +
   * clean object model (ie Project/Target/Task)
   
  +  [ACCEPTED]
  +
   * good event model to integrate well with IDE/GUI/whatever
   
  +  [ACCEPTED]
  +
   * use a consistent naming scheme for attributes across all tasks
   
  +  [ACCEPTED]
  +
   * keep build file syntax as compatible to Ant1 as possible -
     i.e. don't break something just because we can.
   
  +  [ACCEPTED]
  +
   * keep the interface for Tasks as similar to the one of Ant1 as
     possible - i.e. don't break something just because we can.
   
  +  [ACCEPTED]
  +
   * Ant should be cancelable
  +
  +  [ACCEPTED]
   
  -* no commit of new features without documentation (ouch 8-)
  +* no commit of new features without documentation
   
  +  [ACCEPTED AS GUIDELINE]
  +
   * no commit of new features without testcases
   
  +  [ACCEPTED AS GUIDELINE]
  +
   III. Things that are simple, easy to implement, where we expect the
   committers to agree
   ======================================================================
  @@ -117,27 +196,47 @@
   * namespace support so different concerns can occupy different namespaces
     from ant (thus SAX2/JAXP1.1)
   
  +  [ACCEPTED]
  +
   * Java2
   
  +  [ACCEPTED]
  +
   * remove all deprecated methods, attributes, tasks
   
  +  [ACCEPTED]
  +
   * allow all datatypes to be defined anywhere - i.e. as children of
     project as well as of target.
   
  +  [ACCEPTED]
  +
   * make properties fully dynamic, i.e. allow their value to be reassigned
   
  +  [will need more discussion because of vote by Glenn McAllister and
  +                                                Conor MacNeill]
  +
   * unify the namespace of all data types (ie properties + filesets +
     patternset + filtersets).
   
  +  [ACCEPTED]
  +
   * add a user defined message if a target will be skipped because the
     if/unless attribute says so.
   
  +  [ACCEPTED]
  +
   * allow user-datatypes to be defined via a <typedef> similar to <taskdef>.
   
  +  [ACCEPTED]
  +
   IV. Things we probably agree upon but need to discuss the details or
   decide between several possible options.
   ======================================================================
   
  +[ACCEPTED] means, the goal/idea is fine, not that a decission on a
  +particular implementation has been made.
  +
   * 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). 
  @@ -147,55 +246,80 @@
     (ie GUITask implements Task). This way the GUI tasks could be W3C
     DOM Elements, have property vetoers/listeners etc.
   
  +  [ACCEPTED]
  +
   * support for numerous frontends - from command line over GUI to servlets
   
     corollary of the above?
   
  +  [ACCEPTED]
  +
   * 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
   
  +  [ACCEPTED]
  +
   * provide utility classes to aid in building tasks. ie like up-to-date
     functionality abstracted
   
     Need to become more specific here.
   
  +  [ACCEPTED]
  +
   * make ant-call a low cost operations so it can certain
     optional/template-like operations
   
     corollary of "fully interpreted at runtime"?
   
  +  [ACCEPTED]
  +
   * 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.
   
  +  [ACCEPTED]
  +
   * 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?
   
  +  [ACCEPTED]
  +
   * allow tasks to be loaded from jars. tasks should be indicated by
     either xml file in TSK-INF/taskdefs.xml or manifest file.
   
  +  [ACCEPTED]
  +
   * allow documentation to be stored in .tsk jars
   
     corollary of the two points above?
   
  +  [ACCEPTED]
  +
   * better scripting/notification support so the hooks are available to
     send notifications at certain times.
   
     Which hooks and where?
   
  +  [will need more discussion because of vote by Peter Donald and
  +                                                Simeon Fitch]
  +
   * separate tasks into .tsk jars somehow. (Probably via function - ie
     java tasks, file tasks, ejb tasks).
   
     Decide on categories.
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * make separate build files easy (ala AntFarm) and importing different
     projects a breeze
   
  +  [ACCEPTED]
  +
   * 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
  @@ -204,28 +328,40 @@
     Three ideas so far: a CSS like language, a <taskconfig> element,
     properties following a specific naming scheme.
   
  +  [ACCEPTED]
  +
   * support more control over the properties that are going to be passed
     to subprojects (modules)
   
  +  [ACCEPTED]
  +
   * 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.
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * 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?
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * Task to prompt for user input.
   
     Does affect core as we need a means to request input from the Frontend.
   
  +  [ACCEPTED]
  +
   * Add cvs login feature.
   
     Requires handling of user input.
   
  +  [ACCEPTED]
  +
   * Easier installation process. GUI - maybe webstart from the homepage.
   
     This includes asking the user whether he wants to use optional tasks
  @@ -236,18 +372,28 @@
     text files with fixCRLF task; on UNIX, makes scripts executable.  
     Could also modify ant scripts with the location of ANT_HOME.
   
  +  [ACCEPTED]
  +
   * Logo for Ant.
   
  +  [ACCEPTED]
  +
   * detach Ant from System.err/.in/.out.
   
     Beware of problems with spawned processes.
   
  +  [ACCEPTED]
  +
   * better subproject handling
   
     Whatever that means in detail.
   
  +  [will need more discussion because of vote by Conor MacNeill]
  +
   * build files should be declarative in nature
   
  +  [ACCEPTED]
  +
   V. Things we probably don't agree on. 
   ======================================================================
   
  @@ -481,4 +627,9 @@
   -----------
   
   * internationalization
  +
  +VI. entries that have been submitted too late
  +=============================================
  +
  +* Integration of the depends task and javac tasks
   
  
  
  

Mime
View raw message