diff --git a/docs/ant2/requested-features.html b/docs/ant2/requested-features.html new file mode 100644 index 000000000..1304a886b --- /dev/null +++ b/docs/ant2/requested-features.html @@ -0,0 +1,1090 @@ + + + +

+
Requested Features for Ant2
+

+ +

+I. Things that don't affect the core but are requests for new tasks or +enhancements to existing tasks. +

+ +"Accepted" for a task doesn't mean that +task will be a core task (or even be supplied by a voter), just that having +it (as an optional task) would be acceptable. +

+ + +  Accepted + + +

+
  • +Add a new datatype filterset to group token-filters. +
    •  +
    + +
    +
  • +Make usage of particular filters/filtersets explicit in copy tasks. +
    •  +
    + +
    +
  • +Make facade tasks for things like <javac> +(JikesImpl, ModernImpl, etc.). +(One candidate is <jar>, with implementations for +a <fastjar>, for example.) +
    •  +
    + +
    +
  • +Unify multiple similar tasks to use similar forms (eg., all the +<javacc>-type +tools). +
    •  +
    + +
    +
  • +Obfuscating task. +
    •  +
    + +
    +
  • +Better scripting/notification support so the hooks are available to +send notifications at certain times. +
    •  +
    + +
    +
  • +Add an <ant> task that will find build files according +to a fileset and invoke a common target in them. (<anton>?) +
    •  +
    + +
    +
  • +Add a JavaApply task that executes a given class with files from a +fileset as arguments (similar to <apply>). +
    •  +
    + +
    +
  • +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?) +
    •  +
    + +
    +
  • +Better docs (eg., more examples, tutorials, beginner documents, reference +sheets for tasks, printable version, etc.). +
    •  +
    + +
    +
  • +RPM task. +
    •  +
    + +
    +
  • +Task for splitting files (head/tail/split-like functionality). +
    •  +
    + +
    +
  • +Task to create XMI from Java. +
    •  +
    + +
    +
  • +Socksified networking tasks, SSH tasks. +(Peter Donald expressed some legal concerns that might need to be overcome, +depending on the implementation.) +
    •  +
    + +
    +
  • +A reachable task that works much like <available>, +for network URLs. +
    •  +
    + +
    +
  • +Task to extract classes from a jar-file that a given class depends on. +(Based on <depend> or IBM's JAX, for example.) +
    •  +
    + +
    +
  • +Unify <available> and <uptodate> +into a more general +<condition> task – support +AND/OR of +several tests here. +(Will need more discussion because of vote by Peter Donald.) +
    •  +
    + +
    +
  • +JSP-compilation task. (Sounds like a candidate for a facade task.) +
    •  +
    + +
    +
  • +URL-spider task that checks links for missing content or server errors. +
    •  +
    + + +  Rejected + +
    +
  • +Make the default logger's output clear, informative, and terse. (Rejectors +think it already is.) +
    • + + +
    +
  • +Add an attribute to <property> to read in an entire file +as the value of a property. +
    •  +
    + +
    +
  • +Make PATH-handling consistent. Every task that has a PATH attribute +must also accept references to PATHs. +
    •  +
    + +
    +

    +II. Goals that need to be abstract until we get into design +decisions. +

    + +During the 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". +

    + + +  Accepted + + +

    +
  • +Provide a clear mission statement for Ant. +
    •  +
    + +
    +
  • +Main goals: simplicity, understandability, extensibility. +
    •  +
    + +
    +
  • +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/etc. +
    •  +
    + +
    +
  • +Use a consistent naming scheme for attributes across all tasks. +
    •  +
    + +
    +
  • +Keep build-file syntax as compatible to Ant1 as possible +(ie., don't break something just because we can). +
    •  +
    + +
    +
  • +Keep the interface for tasks as similar to that of Ant1 as +possible (ie., don't break something just because we can). +
    •  +
    + +
    +
  • +Ant should be cancelable. +
    •  +
    + + +  Accepted As Guideline + + +
    +
  • +No commit of new features without documentation. +
    •  +
    + +
    +
  • +No commit of new features without test-cases. +
    •  +
    + +
    +

    +III. Things that are simple and easy to implement, where we expect the +committers to agree. +

    + + +  Accepted + + +
    +
  • +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 (ie., as children of +project as well as of target). +
    •  +
    + +
    +
  • +Make properties fully dynamic (ie., allow their value to be reassigned). +
    •  +
    + +
    +
  • +Unify the namespace of all data types (ie., properties + filesets + +patternsets + filtersets). +
    •  +
    + +
    +
  • +Add a user-defined message if a target will be skipped as a +result of the specified if/unless. +
    •  +
    + +
    +
  • +Allow user datatypes to be defined via a <typedef> +similar to <taskdef>. +
    •  +
    + +
    +

    +IV. Things we probably agree on but need to discuss the details or +decide between several possible options. +

    + +"Accepted" means the goal/idea is fine, not that a decision on a +particular implementation has been made. +

    + + +  Accepted + + +

    +
  • +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 +the object model (ie., GUITask extends Task) or to have Task as an +interface (ie., GUITask implements Task). This way, the GUI tasks could +be W3C DOM elements, have property vetoers/listeners, etc.) +
    •  +
    + +
    +
  • +Support for numerous front-ends – from command-line over GUI to servlets. +(Corollary of the above?) +
    •  +
    + +
    +
  • +Fully interpreted at run-time. (This almost requires some form of +abstraction/proxy that stands in place of tasks till it is +interpreted. This can be hash-tables/simple DOM-like model/whatever.) +
    •  +
    + +
    +
  • +Provide utility classes to aid in building tasks (ie., like +<uptodate> functionality abstracted). +(Need to become more specific here.) +
    •  +
    + +
    +
  • +Make ant-call a low-cost operation so it can do certain +optional/template-like operations. +(Corollary of "fully interpreted at run-time"?) +
    •  +
    + +
    +
  • +Allow facilities to build projects from multiple sources (ie., CSS+XML, +XSLT+XML, Velocity+text or database, from inside jars or normal +build.xml files, 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. (Use +either an XML file in TSK-INF/taskdefs.xml or a +manifest file.) +
    •  +
    + +
    +
  • +Allow documentation to be stored in .tsk jars. +(Corollary of the above two points?) +
    •  +
    + +
    +
  • +Separate tasks into .tsk jars somehow. +(Decide on categories. +Probably via function – ie., java tasks, file tasks, EJB tasks, etc.) +
    •  +
    + +
    +
  • +Make having separate build-files easy (à la AntFarm) and importing different +projects a breeze. +
    •  +
    + +
    +
  • +Provide support for user-defined task configurations – (ie., give +users the ability to specify a default value for attributes (eg., always +use debug="true" in <javac> unless +something else has been specified). +(Three ideas so far: a CSS-like language, +a <taskconfig> element, or +properties following a specific naming scheme.) +
    •  +
    + +
    +
  • +Support more control over the properties that are going to be passed +to subprojects (modules). +
    •  +
    + +
    +
  • +Task to prompt for user input. +(Does affect core, as we need a means to request input from the front-end.) +
    •  +
    + +
    +
  • +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.) +
    •  +
    + +
    +
  • +Build-files should be declarative in nature. +
    •  +
    + + +  Rejected + +
    +
  • +It should be possible to modify details of the actual build (e.g. classpath, +compiler used, etc.) 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?) +
    •  +
    + +
    +
  • +Better sub-project handling +(whatever that means in detail). +
    •  +
    + +
    +

    +V. Things we probably don't agree on. +

    +Datatypes + +

    + +  Accepted + + +

    +
  • +Allow <include>/<exclude> +to work with multiple characteristerics of a file +(ie., include into fileset if file is readable, modified after 29th of Feb, +has a name that matches the pattern "**/*.java" and +the property foo.present is set. Something similar to: +
    +  <include>
+    <item-filter type="name" value="**/*.java"/>
+    <item-filter type="permission" value="r"/>
+    <!-- could optionally be directory or some other system specific features -->
+    <item-filter type="type" value="file"/>
+    <item-filter type="modify-time"
+                 operation="greater-than" 
+                 value="29th Feb 2003"/>
+  </include>
+
    +
    •  +
    + +
    +
  • +Provide support for non-hardwired (ie., loadable) low-level +components (mappers/itemset-filters/converters). Allow them to be +loaded in either globally or via a new classloader. +
    •  +
    + +
    +
  • +Provide support for non-hardwired (ie., loadable) converters. +
    +Q: What is a converter? Is this an implementation detail? +
    +A: Not an implementation detail, but a way to extend the engine +to convert more datatypes. Currently, we have a fixed set that is +expanded on occasion (ie., includes primitive types + File). Instead +of spreading converting code throughout the tasks, it can be centralized +into one component and used by the engine. This becomes particularly +relevent if you build Ant-based testing systems and use Ant in certain +web-related areas. +
    •  +
    + +
    +
  • +Set-arithmetic for fileset/patternset/*set. +
    •  +
    + +
    +
  • +Inheritance of Ant properties/datatypes/context/etc. in project hierarchy. +
    •  +
    + + +  Rejected + + +
    +
  • +Allow mappers to be genericized so that particular features can be modified +during mapping. Something similar to: +
    +  <fileset ...>
+    <include name="*.sh"/>
+    <mapper type="unix-permissions">
+      <param name="user" value="ant"/>
+      <param name="group" value="ant"/>
+      <param name="mod" value="755"/>
+    </mapper>
+  </fileset>
+
    +
    •  +
    + +
    +
  • +Provide datatypes through property tag and remove need for separate +free-standing entities. That is:
    +
    +  <property name="foo">
+    <fileset dir="blah">
+      <include name="*/**.java" />
+    </fileset>
+  </property>
+
    +
    •  +
    + +
    +
  • +Make all datatypes interfaces to allow them to be customized in many +ways. +
    •  +
    + +
    +
  • +Inheritance between Ant datatypes (ie., fileset A inherits from +fileset B (includes all entries in A). +
    •  +
    + +
    +
  • +Homogenize notion of PATHs and filesets. +
    •  +
    + +Ant's goals + +

    + +  Accepted + + +

    +
  • +Provide support for CJAN. +
    +Q: In what way?
    +A: Probably by supplying a set of tasks that download versioned +binaries and their associated dependencies, caching the downloads +in a known place and updating binaries when required. +("When required" being indicated by a change in property values). +
    •  +
    + + +  Rejected (as a primary goal) + + +
    +
  • +Make it possible to re-use the task engine for other things +(ie., Installshield-type app, Peter's cron-server, and other task-based +operations). +
    •  +
    + +Class-loading + +

    + +  Rejected + + +

    +
  • +Force resolution of classes on loading, to identify class-loader +issues early (at least in global classloader). +
    •  +
    + + +
    +
  • +Ignore any classes contained in the damned ext dirs of a +JVM – possibly by launching with something like: +
    +    jar -Djava.ext.dir=foo -jar ant.jar +
    +(Accepted if optional.) +
    •  +
    + +

    +Workspace/sub-build issues + +

    + +  Accepted + + +

    +
  • +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. +
    •  +
    + +
    +
  • +Allow a target to depend on a target in another build-file. +
    •  +
    + +

    + +  Rejected + + +

    +
  • +Project inheritance. (What's this?) +
    •  +
    + +
    +
  • +Target inheritance. That is, the ability to include targets from other +project files, overriding them as necessary (so, cascading project +files). +
    •  +
    + +
    +
  • +Add an attribute to <ant> to feed back the environment +(properties and taskdefs) from the child build to the parent. +
    •  +
    + +
    +
  • +Allow a target to reference properties defined in another build-file. +
    •  +
    + +

    +Documentation system + +

    + +  Accepted (with no decision on which system to use) + + +

    +
  • +Generate docs by Anakia/XSLT. +(Corollary of "move to a system that allows docs to be generated"?) +
    •  +
    + +

    +Task API + +

    + +  Accepted + + +

    +
  • +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. Whatever the method, it +should not impose any cost on run-time, as it is only used a small +percentage of the time (design-time). +
    •  +
    + +
    +
  • +Provide "failonerror"-like functionality to all tasks. +(Provide this as an aspect?? Much like logging aspect or classloader aspect). +
    •  +
    + + +  Rejected + + +
    +
  • +Tasks should have access to its own XML representation. +
    • + + +
    +
  • +Task level if and unless attributes. +
    •  +
    + +
    +
  • +Allow tasks to find out, whether another task has completed successfully. +
    •  +
    + +

    +Logging + +

    +
  • +Allow build-file writers to modify logging (verbosity, for example) +on a target-by-target or task-by-task basis. +
    •  +
    + +
    +
  • +Make loggers configurable via build.xml. +
    •  +
    + +

    +Multi-threading + +

    + +  Accepted + + +

    +
  • +Multi-threaded execution of tasks within the same target. +
    •  +
    + + +  Rejected + + +
    +
  • +Multithreaded execution of targets. +
    •  +
    + +

    +Procedural versus purely declarative + +

    + +  Rejected + + +

    +
  • +Simple flow-control (if-then-else, for) +
    •  +
    + +
    +
  • +Targets should be like methods, including a return value. +
    •  +
    + +
    +
  • +Build-files should be purely declarative. +
    •  +
    + +

    +Properties + +

    + +  Accepted + + +

    +
  • +Ability to manage scoping of properties in general +(ie., target/project/workspace). +
    •  +
    + +

    +Templates + +

    + +  Rejected + + +

    +
  • +It should be possible to provide general/(template?) build +specifications, and to declare, for a concrete item, that it should be +built according to such a general specification. +
    • +
    + +

    +XML issues + +

    + +  Accepted + + +

    +
  • +A built-in mechanism to include build-file fragments – something +that doesn't use SYSTEM entities at all and therefore is +XSchema-friendly, allows for property expansions, etc. +
    •  +
    + +
    +
  • +Allow Ant to farm out attributes and elements that are not +in the Ant namespace to other components (ie., hand doc: elements +to the Documentation component or log: attributes to the Log +policy component, etc. +
    •  +
    + + +  Rejected + + +
    +
  • +Let Ant ignore – but warn – if unknown XML elements or attributes +occur in a build-file. +
    •  +
    + +

    +Core extensions + +

    + +  Accepted + + +

    +
  • +Allow sequence to be specified in "depends" attribute, +or enhance <antcall> to work with current list of executed +targets. +
    •  +
    + +
    +
  • +Provide a way to define the order in which targets that a given target +depends upon get executed. (Same as above?) +
    •  +
    + +
    +
  • +Support nesting tasks into other elements – not just as children of +target – as proposed by Thomas Christen in + +his mail message. +
    •  +
    + +
    +
  • +Define task contexts that define various common aspects (logging, +failure handling, etc.), and assign them to tasks. +
    •  +
    + + +  Rejected + + +
    +
  • +Allow named tasks to be defined by <script> elements. +
    •  +
    + +
    +
  • +Specify an OnFail task or target that runs in case of a build +failure. +
    •  +
    + +
    +
  • +Make if/unless attributes check for the value of a property, not +only its existance. +
    •  +
    + +
    +
  • +Check for more than one condition in if/unless attributes. +
    •  +
    + +

    +Organization + +

    + +  Rejected + + +

    +
  • +Separate CVSes and code hierarchies for: +
    •  + +
    + +

    +Miscellaneous + +

    + +  Accepted + + +

    +
  • +Internationalization. +
    •  +
    + +

    +

    +VI. Things that were submitted late +

    + +

    + +  Rejected + + +

    +
  • +Integration of the <depend> and <javac> +tasks. +
    •  +
    + +
    +
  • +Recursive property resolution (ie., resolving ${dist.${name}.dir}) +
    •  +
    + + + +