Ant GUI Feature List

Version 0.4 (2000/11/06)

Authors: Simeon H.K. Fitch, Chris Todd, Clint Combs, Conor MacNeill, Matthew Kuperus Heun, James Duncan Davidson

The purpose of this document is to capture the proposed feature list for the Ant Graphical User Interface. This is not a hard requirements specification; you won't find the word "shall" in it (other than that one time). :-)

In general, the purpose of the GUI is to allow the quick generation and modification of Ant build files, helping the user define their build process and track down build problems. For it to be successful it must make the user more efficient and productive, insofar as their involvement in build management and use of Ant goes. It should first address the needs of the novice Ant user, and then add abilities for the "power" user. This does not imply that the UI should be "dumbed down", it just means that usability should come before slick but complicated features.

The features are in a loose order of expressed interested by contributors.

  1. Build Management

    2. Once a build file is created, the user will want to start and stop it from the UI. This will serve both as a testing facility as well as a general compile tool. Monitoring of the build can occur through the Ant BuildListener interface.

    1. Build execution.
      1. Initiate a build starting from any task.
      2. Stop a currently active build.
    2. Build monitoring.
      1. Provide feedback on the current status of the build.
        This is where you can have more fun with the directed graph view, where the current build activity is highlighted on the screen, making the whole thing behave like a dynamic state transition diagram. You can then highlight the node where the build fails, etc.
      2. Show log messages from the build, allowing the user to determine the task they originated from.
      3. Provide the ability to filter logged messages, adn to display the messages in color codes corresponding to logging levels.
      4. Allow the installation of custom log listeners
      5. Record runtime statistics to determine bottleneck in the build process
        This may be of limited use, as calling <javac> probably takes the most time. But maybe not.

  2. Build Wizard (auto-configure)

    3. To make starting a new project with Ant as easy as possible, the a wizard type of UI can be used where the user provides some basic information and the application deduces what a default build.xml file for it should look like.

    1. Project attributes.
      1. Provide input for the required project attributes.
        This probably means project name and default target.
    2. Project directories.
      1. Ask for the source directory.
      2. Ask for the destination directory.
      3. Ask for the necessary JAR files.
    3. Project properties.
      1. Provide a default set of project properties.
        In here would be things like classpath, build.compiler, version, etc.
      2. Allow the user to add to or remove from properties the default set of properties.
    4. Task creation
      1. Provide a list of "standard" tasks to insert into the project.
        This would be tasks like <javac> and <javadoc>.
      2. Generate default init, compile, javadoc, and clean targets.
    5. Creation review.
      1. Provide a review of the contents of the generated build.xml file.
      2. Allow the user to go back to any step in the process to change a setting.
      3. Prompt the user to save the build.xml file.

  3. IDE Integration

    4. Components of the Ant GUI shoule support plugging into IDEs and code editors.

    1. Emacs
      1. Provide support for launching builds from emacs, and notification of errors.
    2. JEdit
      1. Provide JEdit plug-in.
    3. ProjectBuilder
      1. Provide integration with OSX ProjectBuilder.
    4. NetBeans
      1. Provide integration with the NetBeans IDE.

  4. Project Editing

    5. The Ant UI will be centered around the project file. All operations of the UI will be on a project, whether it be existing or new. How sub-projects are handled (i.e. via the <ant> task) needs to be determined.

    1. Load a project.
      1. Read the native Ant XML format as defined by the Ant users' manual.
      2. When possible, automatically handle changes in the Ant element set, or at least changes to the task set, as well as the valid set of attributes.
        Possible approach: load "default.properties", use introspection to discover attribute set, then reference some other mechanism for attributes that are manifested as properties.
      3. Report errors in the XML source.
      4. Provide a list of recently opened documents for quick reloading.
    2. View project contents.
      1. View the project in it's XML source format.
      2. View the project in a non-source format.
        This is left ambiguous to keep the implementation out of the requirements. The different presentation formats are likely to evolve over time.
      3. View the project properties.
      4. View the project contents (tasks).
    3. Modify a project.
      1. Edit via the XML source.
      2. Edit properties via a property sheet.
      3. Provide facility for editing XML references used in the build file.
    4. Save a project.
      1. Save to the native Ant XML format as defined by the Ant users' manual.
      2. Default save name is "build.xml".
      3. Verify before overwriting existing file when in "Save as" mode.
    5. Create a new project.
      1. Define a project name.
      2. Define the default target.
      3. Define the project base directory.

  5. Task Editing

    6. Tasks define what it is that Ant is to do, and will be the object most edited in the UI. Task is to Paragraph as Project is to Document.

    1. View tasks.
      1. View a sorted list of tasks.
        Provide sorting based on name, depth in dependency tree, how many tasks depend in it...
      2. View tasks as a directed graph.
        Need a good graph editing library. Looked at GEF but it still needs a lot of work, to make it easily reusable. Long term status unknown.
      3. View tasks as a dependency tree.
      4. View task as a properties sheet.
      5. Provide dependency viewing, both immediate and "flattened" views.
    2. Modify task.
      1. Allow editing of a task via a property sheet.
      2. Allow editing of a task via XML source.
      3. Allow the graphical editing of task dependencies
        This is where you can go hog wild with the component wiring type of UI.
      4. Allow non-graphical editing of dependencies.
      5. Provide detection of circular dependencies.
      6. Facilitate definition of conditional tasks with evaluation editor.

  6. Build File Source Editing

    7. This section listes desired features for editing the Ant build file directly. Some components of this could be met by a generic XML editing capability, but other parts will be Ant specific features.

    1. XML Editor.
      1. Provide syntax higlighting.
      2. Provide auto-indentation.
      3. Provide smart tag completion.
      4. Provide visual highlighting of syntax errors.
      5. Support auto-reparsing of contents and model update.

    Copyright © 2000 Apache Software Foundation. All rights Reserved.