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 |
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:
Creates documentation for the 2 files selected, with the output generated in the current directory.
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.
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:
Work to do:
Copyright © Software Systems Generator Research
Group. All rights reserved.
Revised: January 25, 2006.