|
Spec-Zone .ru
спецификации, руководства, описания, API
|
javafxdoc - JavaFX Documentation Utilityjavafxdoc - JavaFX Documentation Utility. This tool extracts formatted comments
embedded in JavaFX source code files and organizes and displays those comments in HTML format.
javafxdoc [options] [packagenames] [sourcefilenames] [-subpackages] pkg1:pkg2:... [@argfiles]
options- Command-line options.
packagenames- A series of names of packages, separated by spaces, such as
javafx.langjavafx.xmlorjavafx.gui.effect. You must separately specify each package that you want to document. Wildcards are not allowed. Use-subpackagesfor recursion. Thejavafxdoctool usessourcepathto look for these package names.sourcefilenames- A series of source file names, separated by spaces, each of which can begin with a path and contain a wildcard such as asterisk (*). The
javafxdoctool processes every file name ending with.fx, where the file name stripped of that suffix is a legal module name (see ). Therefore, you can name files with dashes (such asX-Buffer), or other illegal characters in order to prevent them from being documented. The path that precedes the source file name determines wherejavafxdocwill look for the file. (Thejavafxdoctool does not usesourcepathto look for these source file names.) Relative paths are relative to the current directory, so passing inButton.fxis identical to./Button.fx. For example, a source file name with an absolute path and a wildcard is/home/src/java/awt/Graphics*.fx.subpackages- Generates documentation from source files in the specified packages and recursively in their subpackages. An alternative to supplying package names or source file names.
@argfiles- A command line argument file contains a list of
javafxdocoptions, packagenames and sourcefilenames, in any order. Wildcards (*) and-Joptions are not allowed in these files.
To shorten or simplify thejavafxdoccommand line, you can specify one or more files that themselves contain arguments to thejavafxdoccommand (except-Joptions). This enables you to createjavafxdoccommands of any length.
Arguments can be in any order. See Processing Links for details explaining how thejavafxdoctool determines which source code files to process.
The javafxdoc tool parses the declarations and documentation comments in a set of
JavaFX Script source files and produces a corresponding set of HTML pages describing (by default)
the public and protected classes, attributes, and functions. You can use it to generate Application Programming
Interface documentation or implementation documentation for a set of source files.
This tool is intentionally very similar to the Java
tool.
You can run the javafxdoc tool on entire packages, individual source files, or both.
When documenting entire packages, you can either use subpackages
for traversing recursively down from a top-level directory, or pass in an explicit list of package names. When
documenting individual source files, you pass in a list of source (.fx) file names.
-link extdocURL- Creates links to existing javadoc-generated documentation of external referenced classes.
-linkoffline extdocURL- This option is a variation of
-link. Both options create links to javafxdoc-generated documentation for external referenced classes. Use the-linkofflineoption while linking to a document on the web when thejavafxdoctool itself is offline, that is, it cannot access the document through a web connection.-subpackages package1:package2:...- Generates documentation from source files in the specified packages and recursively in their subpackages.
-sourcepath sourcepathlist- Specifies the search path for finding source files (
.fx) when passing package names or-subpackagesinto thejavafxdoccommand.-profile [desktop | mobile ]- Specifies the JavaFX platform. The JavaFX SDK supports
desktopandmobile, and defaults todesktop.Internally the-profileoption, which specifies the configuration file, which is used for setting environment variables.-version- Displays the tool version and exits. Note: Use
-J-versionto get the Java platform version
The javafxdoc tool processes files that end in .fx, plus other files
described under Source files.
If you run the javafxdoc tool by explicitly passing in individual source filenames,
you can determine exactly
which .fx files are processed. However, that is not how most developers want to work, as it is simpler
to pass in package names.
You can run javafxdoc three ways without explicitly specifying the source filenames:
In these cases, the javafxdoc tool processes a
.fx file only if its name, after stripping off the .fx suffix, is a legal class name.
For details, see .
During a run, the javafxdoc tool automatically adds cross-reference links to package,
class and member names that are being documented as part of that run. Links appear in several places:
@see tags
@inline tags
@throws tags
@comments tags link to members in classes
You can add hyperlinks to existing text for classes not included on the command line (but generated separately) by
way of the link and linkoffline options.
The javafxdoc tool produces one complete document each time it is run.
It cannot do incremental builds, that is, it cannot modify or directly incorporate results from previous runs of the
javafxdoc tool.
However, it can link to results from other runs, as noted above. The javafxdoc tool
also has the option to save the intermediate data from a set of packages in an XML file.
These intermediate files can be included with a javafxdoc task, to incorporate
previous runs into a complete document.
As implemented, the javafxdoc tool requires and relies on the JavaFX Script compiler to
do its job.
The javafxdoc tool calls part of javafxc to compile the
declarations,
ignoring the member implementation. It builds a rich internal representation of the classes, including the class
hierarchy,
and use relationships, then generates the HTML from that.
The javafxdoc tool also picks up user-supplied documentation from documentation
comments in the source code.
In fact, the javafxdoc tool can run on .fx source files that are pure
stub files with no method bodies.
This means you can write documentation comments and run the javafxdoc tool in the
earliest stages of design while creating the API, before writing the implementation.
When the javafxdoc tool builds its internal structure for the documentation, it loads
all referenced classes.
Because of this process, the javafxdoc tool must be able to find all referenced
classes, whether bootstrap classes,
extensions, or user classes. For more about this requirement, see .
In general, classes you create must either be loaded as an extension or reside in the class path for the
javafxdoc tool.
The javafxdoc tool has the ability to copy or inherit function comments in classes.
Note that attributes do not inherit doc comments.
The javafxdoc tool parses special tags when they are embedded within a JavaFX Script
doc comment.
These doc tags enable you to autogenerate a complete, well-formatted API from your source code. The tags start with
an at sign (@) and are case-sensitive: they must be typed with the uppercase and lowercase letters as shown.
A tag must start at the beginning of a line after any leading spaces and an optional asterisk, or it is treated as
normal text. By convention, tags with the same name are grouped together. For example, put all @see
tags together.
The current tags are as follows:
{@link package.class#member label}- Inserts an in-line link with visible text
labelthat points to the documentation for the specified package, class or member name of a referenced class. This tag is valid in all doc comments:overview, package, module, class, functionandattribute, including the text portion of any tag (such as@return, @paramand@deprecated).@see package.class#member label- Adds a link, with visible text
label, that points to the documentation for the specified name in the JavaFX Script API that is referenced. Thelabelis optional. If omitted, the name appears instead as the visible text, suitably shortened. Use-noqualifierto globally remove the package name from this visible text. Use thelabelwhen you want the visible text to be different from the autogenerated visible text.@throws class-name description- The
@throwsand@exceptiontags are synonyms. Adds a Throws subheading to the generated documentation, with theclass-nameanddescriptiontext. Theclass-nameis the name of the exception that might be thrown by the method. This tag is valid only in the doc comment for a function. Multiple@throwstags can be used in a given doc comment for the same or different exceptions.
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved. Sun is required to provide certain third party notices. Please see Third Party Notices for the text of such notices. |
|