A framework for invoking user-level tasks.

This package provides the necessary infrastructure for writing tasks that do things for users, along the same lines as ADAM A-tasks. An example of use is given in the separate NDTools package.

At the moment all the necessary machinery is provided for invoking tasks from the command line in a way that looks ADAM-like, but it is designed so that, for instance, a GUI-style invoker could be written to invoke the same tasks.

The provided components are as follows:

{@link uk.ac.starlink.task.Parameter}
  is an object which knows about the name, default value, data type, validity constraints etc of a parameter of a task. It also stores the actual value of the parameter when it has been obtained from the environment. When it has obtained a value it can return it as a string. `Parameter` can be subclassed to enforce different validity constraints or so it knows how to return itself as some object other than a string (see for instance {@link uk.ac.starlink.task.IntegerParameter}).
`{@link uk.ac.starlink.task.Environment}`
  is an interface which defines how to request the value of a parameter. It can also tell you about what output stream to use for messages to be dispatched to the user.
{@link uk.ac.starlink.task.TerminalEnvironment}
  is an implementation of `Environment` which assumes a user is sitting at a terminal with standard input and standard output.
{@link uk.ac.starlink.task.TerminalInvoker}
  given a map of task names to `Task` objects will use a `TerminalEnvironment` to invoke tasks from an `args`-style string array.
`{@link uk.ac.starlink.task.Task}`
  is the interface which user tasks themselves have to implement. A Task must be able to return a list of the parameters which it uses; since each parameter knows its name, default value, order on the command line, prompt string etc, this tells the Environment everything it needs to know about how to get the value, including what to prompt the user etc. It must also be able to invoke itself on request. During invocation, it can interrogate its parameters to find out what their values are.

Setting up a user-level package containing tasks is then a case of writing a top-level class with a `main` method which invokes `TerminalInvoker`, and writing a number of classes which implement `Task`. See the NDTools package for an example.

To invoke the same tasks from a GUI you'd want to write something like a `GUIEnvironment` and `GUIInvoker` class.