At 02:32 21/12/00 -0800, Jose Alberto Fernandez wrote: >Here is my vision: > >ANT 2.0 I see as several collaborationg parts that when assemble together >produce a very good OS independent build tool. These parts however, and >maybe only to some extend are loosely coupled to one another, via APIs and >interfaces. These parts are:
agreed. >1) Execution engine. yep. Of at least 2 levels - a task execution engine and a project execution engine. These are separated so that other projects can reuse the task execution engine. >3) XML Language. or a tree structured data-source ;) We already only want to deal with a subset of valid XML (ie can only have text or element but not mixed content) and I can quite easily see other sources of taskdata. (embedded directly into .class file for instalshield app, from ldap/database for cron/job engine, from an xslt processor for stylebook engine etc. >4) User interfaces. I prefer the term AntEater uses (namely FrontEnd) as it is a more useful description I think ;) >1) Execution engine >------------------- > >Certaintly the basic functionality of ANT is its ability to execute >tasks and to follow and resolve dependencies. Whether we consider >projects as especialized tasks, or just targets as specialized tasks, >is not too relevant in principle. I would advocate however for having an >engine that knows as little as possible about tasks as we can do. +1 >Another aspect I consider part of the engine is its ability of >creating an internal representation (what we call today a project) out >of some XML "inspired" source format. No user, nor other of the loosely >defined components should need to know, nor rely on the engine internal >representation. agreed. >Differences with ANT 1.x: >------------------------- > >- In ANT 1.x the engine, knows about certain tasks that have particular >priviledges, like being allowed outside <target>s. This makes very difficult >to extend the model or modified in the future. Right - I am not sure how to deal with this. Ages ago when no tasks were allowed outside targets public outcry ensued ;) The main reason was that it required a magic target and extra dependencies (to setup taskdefs/properties). It may also become more difficult if we move to AntFarms notion of import (thou we could fix it with addition of "magic" on_import targets ...). Not sure what do you think ? >- I believe the current <script> capabilities of ANT 1.x are misguided since >it allows direct manipulation of the internal representation of the engine. >This means that users have access and knowledge of the internal >representation of the projects, whch makes very difficult the evolution >of the engine in the future. I would argue that ANT 2.0 should not allow >or discurage such manipulations. I am beginning to agree with this now. >- I do not think that the GUI nor any other tool should have tight bound >access to the internal representation. Nor the internal representation >should be slanted to support this or that GUI approach. A Java IDE may know >about packages and classes, but it certaintly does not allow users access to >the class file internal representation. An IDE may have the ability to >manipulate the syntactic tree of the language it is specialized for, but do >not manipulate the compiled code produced out of the syntactic elements. I partly disagree. I don't think allowing access by frontends should be banned but requiring access via any non-trivial means (ie w3c DOM) is definetly a no-no ;) > >2) Tasks >-------- > >Tasks are what make ANT, ANT. This is the most important contribution of ANT >and where users investmentments may be most affected when changes happened. >I would argue that ANT 2.0 should keep as much as possible the same >definition of Task as in ANT 1.x. ANTs Task API should be the most solid >and stable part of ANT. agreed. >ANT 2.0 should provide a well balanced predefined set of Tasks providing all >the basic functionality required for building complex Java based projects >which may require the execution of applications beyond what is offered as >part of the JDK. agreed. >ANT 2.0 sould provide the ability to add new sets of tasks, packaged >together as well as the ability to declare individual tasks. and again ;) >Differences with ANT 1.x: >------------------------- > >- We need to define a good set of CORE tasks to be shipped with ANT which >are stable and whose stability is promissed to be maintained. This as >opposed to the curret kitchen-sink approach of having all kinds of tasks >shipped and >maintained by Jakarta-ANT. right. Candidates include packages concerning files, core (ie properties/taskedef/import/datadef etc), jdk-tools, text-tools (replace/fixcrlf/patch etc), util-tools (zip/timestamp etc), net (telnet/ftp/mail/etc) etc. Notice that in most cases they model the package hierarchy that java uses. >- Provide a way to declare and used prepackage Task sets, which Jakarta-ANT >or some other group may define for some set of common build process: EJB >deployment, for example. right - interface/impl setup. >3) XML Language: >--------------- > >On the user front-end ANT builds are represented as XML. The source or >any preprocessing of the XML (XSLT, CSS, etc) is irrelevant with respect to >the ANT engine is concerned. right. >4)User interfaces >----------------- > >ANT 2.0 should provide a CLI interface as will as other interfaces GUI that >can be developed independently. Nor the CLI interface nor other tools >should have a priviledge access to ANT internals. They all should be at the >same level to validate that we are providing the correct functionality. > >ANT should be user interface agnostic. Concepts like Workspace, and so on, >in my opinion relate to the user-experience and GUI usability, they belong >on the GUI tool but not on ANT. User-configuration (CSS, for example) may be >associated to a project by a GUI thru the definition of a workspace, but it >should not be a concept manipulated by ANT. I now agree - thou it would be nice to have the concept of top-level workspace that set "environment/context variables" as in JDDs latest proposal. However I think that this belongs to convention and shouldn't be mandated by the tool - maybe another tool thats over the top can mandate this structure but I don't think base ant should. Which is why I still prefer the AntFarm approach ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
