Ant GUI Requirements

30 Oct 2000 20:48:27 -0000 

I have thrown together the following HTML file
containing a *very* rough set of capabilities for the
Ant GUI.

I hesitate to call it a requirements document, as it
is certainly not written in a formal manner, nor do I
intend it to be fixed. I just wanted to start
recording people's wishes for it so that there could
be a basis for launching work on it.

So I appreciate any feedback, etc. If the group likes
it, would someone be willing to check it into the spec
directory?

Thanks,

Simeon Fitch

PS: anyone open to the name "antidote" over "anthill"?

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/
Title: Ant GUI Requirements

Ant GUI Requirements

Version 0.1 (2000/10/30)

Authors: Simeon H.K. Fitch

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.

  1. Project Management

    2. 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.
    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.

  2. Task Management

    3. 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 task as a properties sheet.
      4. 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.

  3. Build Management

    4. Once a build file is loaded or 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. Allow the installation of custom log listeners
      4. 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.

  4. Build Wizard (auto-configure)

    5. 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.

Reply via email to