After all this discussion I guess I should put my point of view on the table. No, I do not have a proposal coded, and I do not have a complete new rearchitecture of ANT in mind, I did not see too much need for it. Although, looking at some of the proposals I can see that there are quite a few improvements that can be done.
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: 1) Execution engine. 2) Tasks. 3) XML Language. 4) User interfaces. 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. 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. 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. - 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 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. 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. 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. ANT 2.0 sould provide the ability to add new sets of tasks, packaged together as well as the ability to declare individual tasks. 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. - 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. 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. XML is the visible/manageable representation of ANT projects. Tools may interact with the XML representation. Other tools may preprocess the XML representation in order to apply user configuration and other stylistic front-ends. The important point is that Users abstraction on what a build is and how to manipulate it or change it is this XML view. Whether this XML view is seen as text, DOM, JDOM or some other arbitraty representation convertible to XML is irrelevant. Differences with ANT 1.x: ------------------------- - It makes clear what the user model of ANT is and what is not. This lives free range to ANT to evelve independently of any IDE or other environment tools may be using. 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. Difference with ANT 1.x: ------------------------ - In ANT 1.x the CLI interface and the project building process are together as one intermingled code. Some of the proposals try to bring the ANT model closer to a particular GUI view of the world, looking at concepts like workspace, or sharing nodes between ANT and the GUI tool. - I do not think ANT should be slanted to some particular idea of how an interactive tool organizes its building process. That deveates ANT from its major objective which is to be effecient and useful on building Java based projects from ANY environment (including those without a GUI), and maintaining the portability of the build files across environments. ---------------------------- Well this are some on my thoughts. As you can see I have concentrated on what I want ANT to be from the feature set and not on how it does it. However, I think that it is very important the we prvide backward conpatibility, as much as possible, not only at the XML level, but also at the Task level. We need to preserve the investment people have made on ANT. Comments, Jose Alberto
