| # Jedi Tool

Jedi is a tool that allows the user to create documentation for extensions of java programs in similar fashion to Sun's javadoc.

- Command-line invocation
- Architecture
- Implementation Status

## Command-Line Invocation

Jedi invocation is currently handled with the following command options:

>     jedi [options]

>     Usage: -p package1 package2 ...
>            -f file1 file2 ...
>            -r realm1 realm2 ...
>            -e extension1 extension2 ...
>            -o output dir
>     Default directory : .
>     Default extension : .jak

option -p generates documentation for a whole package, that is, all the files with the specified extensions.

option -f generates documentation for the specified files, these names must include the extensions as well.

option -r generates documentation for all the layers in the specified realms. The structure of the realm is preserved.

option -e permits the specification of which file extensions to document. By default only documentation for jak files is generated.

option -o allows the specification of the output directory. The default value is the current directory. If selected with the options -p or -r, a copy of the directory structure will be made to put the generated output in the corresponding directories.

Examples:

- jedi -f /realms/F/FsatsL/Target.jak /realms/F/Target/TargetImpl.jak

Creates documentation for the 2 files selected, with the output generated in the current directory.

- jedi -r /realms/F -o outputDir

Documents all the components of the realm F. One directory will be created in outputDir for each component of the realm where its documents will be placed.

- jedi -p Package1 Package2 -e java

Documents all the java files that are contained in Package1 and Package2. The output will be put in the current directory.

## Architecture

Java and each of the language extensions is represented as a layer that has the four conceptual components:

> API: contains the class hierarchy of the data structures that hold the information of the comments and program structure (methods, fields, classes, etc.). We based our API designs on Sun’s Doclet API .

> Harvester: consists of a BNF grammar file that defines the syntax of the language extension and its corresponding parser. It is responsible for collecting the documentation information for the syntactic structures defined in its grammar and for storing information in the corresponding API data structures.

> Writer: coordinates the order in which harvesting and output generation is done among the different layers. For example, given a package name to document, it first collects the information of all the classes in the package, resolves cross-references, and finally calls the output generation routine for each of those classes.

> Generator: produces as output the HMTL documentation for a parsed program.

## Implementation Status

Current implementation supports basic functionality of document generation

Supported Features:

- Basic javadoc tags.
- Creates two types of documents, classes/interfaces and state machines.
- Grammar equal to mixin and unmixin tools.

Work to do:

- Support of cross references.
- Parser extensibility for customizable tag parsing and documentation.
- For State Machines grammar: Nested states, Root Clause changes, ESList, and Parameters.
- For Base grammar: New, Super, Constructor Refinement
- For AstEmpty grammar: No document generation of nested metaprograms.

ATS Home Page

Copyright © Software Systems Generator Research Group. All rights reserved.
Revised: January 25, 2006.