Parameter | Name / Type / Description |
---|---|
Window Title |
windowTitle : string
Specifies the browser window title for the documentation.
This is the same as
Default Value:
The default value of this parameter will be taken from the
|
Documentation Title |
docTitle : text
Specifies the title to be placed at the the top of the documentation overview (overview summary file).
This is the same as
Default Value:
The default value of this parameter will be taken from the
See Also:
“Generate | Title Page” parameter |
Parameter | Name / Type / Description |
---|---|
Title Page |
gen.titlePage : boolean
Specify whether to generate the Title Page. The title page is available only in single file documentation (generated with PlainDoc.tpl main template). When generated, it will be the very first page of the entire documentation. Related Template: The title page is generated by title-page.tpl template.See Also: “Documentation Title” parameter |
Table Of Contents |
gen.toc : boolean
Specify whether to insert the Table Of Contents of the documentation. Currently, the Table Of Contents is available only in RTF documentation (generated with PlainDoc.tpl main template). However, it is not actually generated. Rather, a special RTF “{TOC}” field is inserted. The real Table Of Contents is generated by MS Word according to that field and style/level paragraph settings specified on the headings of some documentation section. This produces the Table Of Contents with the following structure: To have the Table Of Contents generated, the document should be loaded in MS Word and the {TOC} field updated. For instance, you can press Ctrl-A (select all) and then F9 (update selected fields).Overview....................... Package Summary............. All Classes Summary......... package1....................... class1...................... class2...................... ... package2....................... ... ... Related Template: The Table Of Contents is generated by TOC.tpl template.See Also: “Pagination | Start from new page | Table Of Contents” parameter |
Overview |
gen.overview : boolean
Specifies whether to generate the Overview page/section (an equivalent of the overview-summary.html file generated by the Standard Doclet). It is the front page of Java API documentation and provides a list of all packages with a summary for each. This page can also contain an overall description of the set of packages. In the case of framed HTML documentation (generated by FramedDoc.tpl), the Overview page is always generated and, therefore, this parameter is fixed. In the case of single file (RTF) documentation (generated by PlainDoc.tpl), the Overview section may also include a summary of all documented classes. This is controlled by “Generate | Overview | All Classes Summary” parameter. Related Template: The Overview page/section is generated by overview.tpl template.See Also: “Pagination | Start from new page | Overview” parameter |
gen.overview.packages : boolean
Specify whether the documentation Overview will include the summary of all documented packages. These are the packages containing any documented classes. For instance, when you document only a single class, there will be a package containing it, which will appear in the overview package summary, when this parameter is selected. Related Template: A package summary table is generated by package-summary.tpl template. |
|
gen.overview.packages.groups : list of strings
This parameter is an analog of
The parameter accepts multiple (list) value. Each value item specifies a single package group. Specifying Package GroupA package group is specified as follows:
where
Example:
Specifying Multiple Package GroupsDifferent package groups should be specified with separate items of the whole parameter value. Each value item should define a single group as described above. The items must be separated with one of the allowed item separators (newline or';' ).
Example:
or the same as a single line:
The last form can be used to specify both groups on the Javadoc command line:
(Note: Because here the full parameter value contains spaces,
it is enclosed in quotes to have it treated as a single command-line argument.)
The same can be also specified with two -P options:
Each -P option
adds a separate value item to the 'gen.overview.packages.groups' parameter.
Using Escapes Each character that serves as a value item separator can be equally used within the value item if escaped with a backslash. If a backslash is not consumed by an escape it will be remained in the text as is. To make sure that a backslash is not part of some escape, you may add another backslash. For example, a package group with the title:
can be specified like this:
Sorting OrderThe groups appear on the page in the order of the parameter's value items specifying each group (i.e. in the same order as the package groups are specified on the command line). The packages are alphabetized within a group.Packages Outside GroupsIf you specify no package groups (the parameter value is empty), all packages are placed in one group with the heading “Packages”.If the all groups do not include all documented packages, any leftover packages appear in a separate group with the heading “Other Packages”, which is printed the last. Default ValueThe default value of this parameter is produced from all-group
options found on the Javadoc command line. Each -group option
is converted to a single value item of this parameter.
So, you can use Standard Doclet's
|
|
gen.overview.allClasses : boolean
Specify whether the documentation Overview will include the summary of all documented classes. Related Template: A class summary table is generated by class-summary.tpl template.See Also: “Pagination | Start from new page | All Classes Summary” parameter |
|
Package Overviews |
gen.package : boolean
Specifies whether to generate a Package Overview page/section for every documented package (an equivalent of the package-summary.html file generated by the Standard Doclet).
When this parameter is selected ( Note: This parameter/group is available only in PlainDoc.tpl template. In case of framed documentation, the Package Overviews are generated anyway.Related Template: A Package Overview page/section is generated by package.tpl template.See Also: “Pagination | Start from new page | Package Overviews” parameter |
gen.package.classes : boolean
Specify whether Package Overview will include the summary of all documented classes contained in that package. Related Template: A class summary table is generated by class-summary.tpl template. |
|
Class Detail |
gen.class : boolean
Specify whether to generate a Class Details page/section for each class or interface being documented. It includes the class description, various reference lists about it, as well as the details of all documented members of that class (except nested classes). This provides the bulk of the whole Java API documentation. Note: In the case of framed HTML documentation (generated by FramedDoc.tpl), the class details are always generated and, therefore, this parameter cannot be unchecked.Related Template: Each Class Detail page/section is generated by class.tpl template.See Also: “Pagination | Start from new page | Class Detail” parameter |
gen.class.member.summary : boolean
Specifies whether to include the summary of class members (i.e. fields and methods) and inner classes. |
|
gen.class.member.summary.inherited : boolean
Specify whether to include the lists of inherited inner classes, fields or methods. |
|
gen.class.member.summary.inherited.exclude : list of strings
This parameter allows you to exclude the lists of inner classes, fields or methods that are inherited from the classes/interfaces which belong to the specified packages. For instance, you may want to suppress the long lists of the class members inherited from standard Java API classes and, thereby, to reduce the output documentation
The packages, whose classes/interfaces should not appear in the "inherited from ..." lists,
are specified as the list of package patterns separated with newlines or colons (
A package pattern can be any package name, or can be the start of any package name followed by an asterisk (* ).
The asterisk is a wildcard meaning “match any characters”. This is the only wildcard allowed.
See Also: DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
|
gen.class.member.detail : boolean
Specify whether to include the details of class members (i.e. fields and methods).
If |
|
gen.class.member.detail.constantValues : boolean
Specify whether to show the constant field values directly in the field documentation headers. For example:
This is an alternative to the
constant field values page
offered by the standard Javadoc (which can be equally generated by
JavadocPro template set).
See Also: “Generate | Cross-Reference Pages | Constant Field Values” parameter |
|
Cross-Reference Pages |
gen.refs
The parameter group to control the generation of various reference pages. Note: These parameters are avalaible only in FramedDoc.tpl main template, which generates framed HTML documentation. |
gen.refs.allClasses : boolean
Specify whether to generated All Class Summary page, which is loaded when clicking on “All Classes” item in the navigation bar.
It is a replacement of the standard Unlike the standard one, All Class Summary page shows not just the list of pure class names but rather a summary of all classes with the first sentence description of each class. It is also available in the FRAMES mode. Related Template: The All Classes page is generated by class-summary.tpl template. |
|
gen.refs.use : boolean
Specify whether to generate a “use” page for each documented class and package. The page describes what packages, classes, methods, constructors and fields use any API of the given class or package. Default Value: The default value of this parameter is set according to theRelated Templates: The Use pages are generated by package-use.tpl and class-use.tpl templates. |
|
gen.refs.tree : boolean
Specify whether to generate class/interface hierarchy pages. These are the pages you reach using the “Tree” button in the navigation bar. Default Value: The default value of this parameter is set according to theRelated Template: The Class Hierarchy pages are generated by class-tree.tpl template. |
|
gen.refs.deprecatedList : boolean
Specify whether to generate the
deprecated API page
( Note: This parameter has no effect on the generation of the deprecated API throughout the rest of the documentation, which is controlled separately by “Include | Deprecated API” parameter.Default Value: The default value of this parameter is set according to theRelated Template: The Deprecated API page is generated by deprecated-list.tpl template. |
|
gen.refs.index : boolean
Specify whether to generate an index. Default Value: The default value of this parameter is set according to theRelated Templates: The index is generated by two templates: |
|
gen.refs.index.split : boolean
Specify whether to split the index file into multiple files, alphabetically, one file per letter, plus a file for any index entries that start with non-alphabetical characters. Default Value: The default value of this parameter is set according to the |
|
gen.refs.serializedForm : boolean
Specify whether to generate the serialized form page. That page contains information about serializable and externalizable classes. Each such class has a description of its serialization fields and methods. This information is of interest to re-implementors, not to developers using the API. While there is no link in the navigation bar, you can get to this information by going to any serialized class and clicking “Serialized Form” in the “See also” section of the class comment. Related Template: The Serialized Form page is generated by serialized-form.tpl template. |
|
gen.refs.constantValues : boolean
Specify whether to generate the
constant field values page
( Related Template: The Constant Field Values page is generated by constant-values.tpl template.See Also: “Generate | Class Detail | Member Detail | Constant Field Values” parameter |
|
Help |
gen.help : boolean
Specify whether to generate the help page. This is the page you reach using the “Help” button in the navigation bar. Default Value: The default value of this parameter is set according to theRelated Template: The Help page is generated by help-doc.tpl template. |
Navigation bar |
gen.navbar : boolean
Specify whether to generate the navigation bar located at the top and bottom of the generated HTML pages. Notes:
The default value of this parameter is set according to theRelated Template: All navigation bars are generated by the same navbar.tpl template. |
gen.navbar.headerText : text
This parameter is similar to
Additionally, when the header text is specified, it is inserted also at the top of the
Default Value:
The default value of this parameter will be taken from the
|
|
gen.navbar.footerText : text
This parameter is similar to
The footer text may contain HTML tags and white space. Note: When the footer text is not specified, the header text (specified in “Header Text” parameter) will be used instead of it.Default Value:
The default value of this parameter will be taken from the
|
|
Bottom Text |
gen.bottomText : text
This parameter is similar to
The bottom text may contain HTML tags and white space. Default Value:
The default value of this parameter will be taken from the
|
About (footer) |
gen.about : enum {"full", "short", "none"}
Specify whether to generate the “About” section added at the bottom of each generated document. This section shows certain information about DocFlex/Javadoc software, which powers this Java API Documentation Generator. Possible Values:
Actually, all what you can see in the “About” section is generated entirely by about.tpl template. |
Parameter | Name / Type / Description | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Deprecated API |
include.deprecated : boolean
Specify whether to include deprecated API in the documentation.
When the parameter is unselected ( Default Value: The default value of this parameter is set according to theSee Also: “Generate | Cross-Reference Pages | Deprecated List” parameter |
||||||||||||||||||
Tags |
include.tag
This group of parameters controls whether to include in the generated docs the sections associated with some tags. |
||||||||||||||||||
include.tag.since : boolean
Include in the generated docs the “Since” sections associated with the
Default Value: The default value of this parameter is set according to the |
|||||||||||||||||||
include.tag.version : boolean
Include the
Default Value: The default value of this parameter is set according to the |
|||||||||||||||||||
include.tag.author : boolean
Include the
Default Value: The default value of this parameter is set according to the |
|||||||||||||||||||
include.tag.custom : list of strings
This parameter is an analog of the
It allows you to include in the generated output the documentation of your custom tags, specify the tag headings as well as their ordering. You will be able also to redefine the headings and ordering of the standard tags (such as @param, @see, @author, etc). This parameter accepts multiple (list) value. Each value item specifies how a single tag should be documented. Specifying Single TagDocumenting of a single tag is specified with the following expression:
The tagname is the name of the tag for which this setting applies.
The taghead is the heading for the tag documentation.
Omitting taghead causes tagname to be used as the heading
(unless this is a standard tag). If the tag has no text (specified in the Java comment),
only the heading will appear in the generated output.
The
Examples: The following parameter value item:
specifies a custom @threadsafe tag to be documented anywhere it is used with the heading message:
Can be called safely from multiple threadsThe following value item specifies that @todo tag should be processed only with constructors,
methods and fields:
Notice the last colon (:) above is not a separator, but is part of the heading text (as shown below).
You would use either tag option for source code that contains the tag @todo, such as:
This line would produce output something like:
To Do:The documentation for this method needs work. Use of Colon in Tag Name A colon can be used in a tag name if it is escaped with a backslash. For this doc comment: use the following setting of the parameter value:/** * @ejb:bean */
Specifying Multiple TagsDocumenting of different tags should be specified in different items of the whole parameter value. Each value item should define how to document a single tag as described above. The items must be separated with one of the allowed item separator characters (newline or ';' ).
Example:
or the same as a single line:
The last form can be used to specify both tags on the Javadoc command line:
(Note: Because the full parameter value here contains spaces,
it is enclosed in quotes in order to make it treated as a single command-line argument.)
The same can be also specified with two
Each -p option adds a separate value item to 'include.tag.custom' parameter.
Tag Ordering
The tags will appear in the output documentation in the same order as they are specified in the value items
of this parameter. For instance, in the example above, the documentation of Using this parameter, you can also redefine the ordering of the standard tags, for example:
This setting says that @version tag should be documented before the custom @todo tag followed
by the documentation of @see tags.
Any other standard tags will be documented as usual in a certain some predefined order before the tags specified in this parameter. Using EscapesEach character that serves as a value item separator can be equally used within the value items if escaped with a backslash. For example, documenting of the tag:
can be specified like this:
If a backslash is not consumed by an escape it will be remained in the text as is.
To make sure that a backslash is not part of some escape, you may add another backslash.
A sequence of two backslashes ("\\" ) is an escape by itself, which represents a single backslash.
This is important because backslashes may be used also in a secondary system of escapes
(e.g. to escape ':' within the tag name).
For example, a string like this:
will be initially processed and broken into two value items:
then, processed further to document allmy;odd;tag:a:\My Odd Title\ ejb\:bean:a:EJB Bean: '@my;odd;tag' tags
with "\My Odd Title\" title and all '@ejb:bean' tags with
"EJB Bean:" title.
Default ValueThe default value of this parameter is produced from all-tag
options found on the Javadoc command line. Each -tag option
is converted to a single value item of this parameter.
So, you can use Standard Doclet's |
Parameter | Name / Type / Description |
---|---|
Package Qualifiers |
show.qualifier : boolean
This parameter/group controls whether to show qualifying package name ahead of class names in parameters, types, referenced classes (like exception lists, implemented interfaces, etc.), specified with @see tags and {@link} tags in comments.
When this parameter is unchecked ( Note: To omit package qualifiers only for selected packages, please use the nested parameter “Omit for Packages”.Default Value: The default value of this parameter is calculated according to the |
show.qualifier.omit : list of strings
Specify the packages whose qualifying names should be omitted from ahead of class names in the output.
The packages to omit are specified as the list
of package patterns separated with newlines or colons (
A package pattern can be any package name, or can be the start of any package name followed by an asterisk (* ).
The asterisk is a wildcard meaning “match any characters”. This is the only wildcard allowed.
Default Value: The default value of this parameter is calculated according to theSee Also: DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
|
Link Titles (Tooltips) |
show.linkTitle : boolean
Specify whether to generate hyperlink titles.
In HTML, hyperlink titles are specified using
Most browsers will interpret it as a hyperlink tooltip
(a tiny window with the text that appears near the hyperlink
when the mouse cursor is moved over it).
Such tooltips can be used to quickly see additional information about the linked text. For instance, when the link appears on a Java class name, its tooltip may reveal what kind of class it is (e.g. ordinary class, interface, enum or annotation type) and which package it belongs to. |
You can identify classes and members to be documented both:
The overall effect will be that the generated JavaDoc will look as if the excluded classes themselves did never exist at all, however, everything else is in place and correct.
In that case, the generated Java API documentation will effectively reorganize your actual Java implementation, excluding certain classes and showing some of their member as if they belong to other classes (derived from the excluded ones). In fact, there is nothing wrong with such a reorganization, because the standard Javadoc actually does it too. For instance, when you specify documenting only public classes, the package-local ones will get excluded, but the public members defined in them may show up as part of the documented classes, which inherit them. |
C1
extends class C2
C2
extends class C3
C3
contains a public method m()
-- which is supposed to be documentedC3
must be excluded from the documentation.
What will happen with the method m()
?
It will be shown in the documentation as declared in the class C2
!
Then, for the class C1
, m()
must appear as inherited from the class C2
(rather than from the class C3
, as it actually is in the code).
C1
extends class C2
C2
implements interface I
C2
contains a private field F
I
contains a public field F
-- which might be documentedI
must be excluded from the documentation.
What will happen with the field I.F
? Actually, nothing!
It shouldn't get in the documentation because it is shadowed by C2.F
,
which is private and, therefore, must be invisible.
C1
defined like this:
and classclass C1{ ... public void mmm (V param); }
C2
that extends C1
:
Now, suppose that classclass C2 extends C1{ ... }
C1
should be excluded from the documentation,
but its method C1.mmm()
should not.
Then, showing that method like:
C2.mmm (V param)
would be incorrect because class C2
has no type variable 'V'
(and even if it had that would be actually a different variable).
So, what would be correct then? Actually this:
C2.mmm (String param)
And that's how it will be process and documented by this template set!
Parameter | Name / Type / Description | |
---|---|---|
By Tags |
filter.byTags
This group of parameters allows you to filter classes and members by tags. You can identify classes and members to be documented both:
-sourcepath
option or directly).
If you need to filter anything contained in the compiled object code,
use filtering by annotations instead (see
“Filter Classes & Members | By Annotations” parameter group)
|
|
filter.byTags.for.packages : list of strings
Specify the packages, for which filtering by tags applies. When this parameter is specified, only classes that belong to the specified packages may be excluded from the documentation according to any filtering by tags criteria (both explicit and implicit ones).
The packages are specified as the list of package patterns separated with newlines or colons (
A package pattern can be any package name, or can be the start of any package name followed by an asterisk (* ).
The asterisk is a wildcard meaning “match any characters”. This is the only wildcard allowed.
See Also: DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.include
This group of parameters allows you to include in the generated documentation only classes, fields and methods marked with the specified tags. |
||
filter.byTags.include.all : list of strings
Specify tags, by which both classes and class members (i.e. fields, constructors and methods) are included in the generated documentation. When this parameter is specified, the entire documentation scope will be limited as follows. A class is included in the documentation only when at least one of the conditions is met:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.include.classes : list of strings
With this parameter you can explicitly identify classes to be documented, while keeping in the documentation some of the fields and methods defined in the classes to be excluded. The tags specified in this parameter are treated as follows. A class is included in the documentation only when it has one of the specified tags. Each inheritable member of any excluded class, which has subclasses to be documented, will be shown as if it belongs to those of them that are the nearest descendants of the member's original class.
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.include.members : list of strings
This parameter allows you to specify precisely which class members (fields & methods) should be documented. The tags specified in this parameter are treated as follows. A class member is included in the documentation only when it has one of the specified tags. Note: When the class containing such a member must be excluded, the member itself may still appear in the documentation. If that class has subclasses to be documented, the member will be shown as if it belongs to those of them, which are the nearest descendants of the member's original class.
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.exclude
This group of parameters allows you to exclude from the generated documentation classes, fields and methods with the specified tags (custom or not). |
||
filter.byTags.exclude.all : list of strings
Specify tags by which both classes and class members (i.e. fields, constructors and methods) are completely excluded from the generated documentation. A class is excluded when at least one of the conditions is met:
The multiple exclude-tag names must be separated with new lines ('\n'), semicolons (';') or colons (':'). For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.exclude.classes : list of strings
This parameter allows you to hide completely from the generated documentation some intermediate classes of your internal implementation (that for some reasons need to be public), while keeping in the documentation some of the fields and methods defined in those excluded classes, which you actually want to be part of your open API. The tags specified in this parameter are treated as the following. A class will be never mentioned in the documentation when at least one of the conditions is met:
The overall effect should be that the generated documentation will look as if the excluded classes themselves did never exist at all, however, everything else is in place and correct. (For that matter, see also description of the "Filter Classes & Members" parameter group.) The multiple exclude-tag names must be separated with new lines ('\n'), semicolons (';') or colons (':'). For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byTags.exclude.members : list of strings
Specify tags by which only class members (i.e. fields, constructors and methods) are selectively excluded from the generated documentation. A class member, which otherwise (without this parameter) would be documented, is excluded when it has at least one of the specified tags. The multiple exclude-tag names must be separated with new lines ('\n'), semicolons (';') or colons (':'). For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
By Annotations |
filter.byAnns
This group of parameters provides an alternative way to filter classes and members that appear in the generated documentation. As you know, one of the new language features introduced in Java 5 is annotations. Annotations are essentially similar to tags. However, unlike tags, they are specified not within Java comments, but directly in Java code. That is, annotations are processed by the Java compiler itself and can be retained in the compiled binary classes (which is impossible with tags). So, you can use annotations the same as tags to mark some of your classes and members to filter them out or retain in the generated documentation. But, why would you need to use annotations? Why are tags not enough? Let's suppose, you have a library of some core Java classes for internal use. That library is quite a separate thing. So, you may use it in different projects (or different people are using it). Therefore, you maintain that library in a pre-compiled binary form as a jar-file. Now, you develop a project, in which you use that internal library. You want to publish certain classes of that project as an open API to your system. But some of those classes are inherited from the classes contained in your internal library (or implement interfaces from it). An ordinary Java API documentation generated by Javadoc would mention those internal classes as superclasses (implemented interfaces) of your API. But you want them to be invisible in the published documentation. They are internal after all! So, how can you do that? Marking your internal classes with tags will not work, because your tags will not get into the compiled jar-file. Here is where annotations can help! Let's see how you can do it. First, you need to define your annotation type like the following (all names are for example): Those lines should be saved aspackage myprojects.core.util; public @interface Internal { } Internal.java file located in
'myprojects/core/util' package.
Note that as with any Java class, the defined annotation type has a fully qualified name,
which will be the string: Now, you can use this annotation type to mark your internal classes. Here is how: After that, you can exclude all classes marked with that annotation from the generated documentation by specifying the annotation type qualified namepackage myprojects.core.classes; ... import myprojects.core.util.Internal; @Internal public class MyIterator { ... } 'myprojects.core.util.Internal'
in the
“Filter Classes & Members | By Annotations | Exclude | Classes”
parameter.
This will equally work both with the classes defined in the Java sources and the binary classes
found on the Javadoc classpath!
|
|
filter.byAnns.for
With these parameters you can limit the scope, to which filtering by annotations applies. (That is the classes that may be excluded from the documentation according to any filtering by annotation criteria -- both explicit and implicitly ones). The limitation is needed because since filtering by annotations potentially extends to all classes involved (including those contained in pre-compiled Java libraries), it may have unwanted side effects.
|
||
filter.byAnns.for.activeSet : boolean
When this parameter is selected (
These are all classes (and packages) initially specified to Javadoc to be documented
and filtered according to the access control options
( |
||
filter.byAnns.for.packages : list of strings
Specify the packages, for which filtering by annotations applies. When this parameter is specified, only classes that belong to the specified packages may be excluded from the documentation according to any filtering by annotation criteria (both explicit and implicit ones).
The packages are specified as the list of package patterns separated with newlines or colons (
A package pattern can be any package name, or can be the start of any package name followed by an asterisk (* ).
The asterisk is a wildcard meaning “match any characters”. This is the only wildcard allowed.
See Also: DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.include
This group of parameters allows you to include in the generated documentation only classes, fields and methods marked with the specified annotations (custom or not). |
||
filter.byAnns.include.all : list of strings
Specify annotation types, by which both classes and class members (i.e. fields, constructors and methods) are included in the generated documentation. When this parameter is specified, the entire documentation scope will be limited as follows. A class is included in the documentation only when at least one of the conditions is met:
java.lang.Deprecated ).
Multiple annotation type names must be separated with new lines ('\n'), semicolons (';') or colons (':').
For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.include.classes : list of strings
With this parameter you can explicitly identify classes to be documented, while keeping in the documentation some of the fields and methods defined in the classes to be excluded. The annotation types specified in this parameter are treated as follows. A class is included in the documentation only when it has an annotation of one of the specified types. Each inheritable member of any excluded class, which has subclasses to be documented, will be shown as if it belongs to those of them that are the nearest descendants of the member's original class.
java.lang.Deprecated ).
Multiple annotation type names must be separated with new lines ('\n'), semicolons (';') or colons (':').
For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.include.members : list of strings
This parameter allows you to specify precisely which class members (fields & methods) should be documented. The annotation types specified in this parameter are treated as follows. A class member is included in the documentation only when it has an annotation of one of the specified types. Note: When the class containing such a member must be excluded, the member itself may still appear in the documentation. If that class has subclasses to be documented, the member will be shown as if it belongs to those of them, which are the nearest descendants of the member's original class.
java.lang.Deprecated ).
Multiple annotation type names must be separated with new lines ('\n'), semicolons (';') or colons (':').
For example:
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.exclude
This group of parameters allows you to exclude from the generated documentation classes, fields and methods with the specified annotations (custom or not). |
||
filter.byAnns.exclude.all : list of strings
Specify annotation types by which both classes and class members (i.e. fields, constructors and methods) are completely excluded from the generated documentation. A class is excluded when at least one of the conditions is met:
Each annotation type must be specified with its fully qualified name (e.g.
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.exclude.classes : list of strings
This parameter allows to hide completely from the generated documentation some intermediate classes of your internal implementation (that for some reasons need to be public), however, to preserve documenting of some fields and methods (defined within those classes), which are supposed to be part of an open API. This may be particularly helpful when you will need next time to change your implementation while keeping intact what you have declared in your open API. The annotation types specified in this parameter are treated as the following. A class will be never mentioned in the documentation when at least one of the conditions is met:
The overall effect should be that the generated documentation will look as if the excluded classes themselves did never exist at all, however, everything else is in place and correct. (For that matter, see also the description of the "Filter Classes & Members" parameter group.)
Each annotation type must be specified with its fully qualified name (e.g.
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
filter.byAnns.exclude.members : list of strings
Specify annotation types by which only class members (i.e. fields, constructors and methods) are selectively excluded from the generated documentation. A class member, which otherwise (without this parameter) would be documented, is excluded when it has an annotation of one of the specified types.
Each annotation type must be specified with its fully qualified name (e.g.
See Also:
DocFlex/Javadoc | Documentation | DocFlex Doclet | Handling Template Parameters | Multi-valued (List) Parameters |
||
Suppress empty packages |
filter.suppressEmptyPackages : boolean
Do not document packages that contain no classes or interfaces included in the documentation scope. Normally, Javadoc does not document empty paclages. But when filtering by tags/annotations is applied, some of the packages may become effectively empty. Yet, they will be still visible in the documentation. This parameter allows you to suppress documenting such packages. |
It is available only in PlainDoc.tpl main template.
Parameter | Name / Type / Description |
---|---|
Generate page columns |
page.columns : boolean
Specify whether to generate page number columns in summary tables. Page numbers substitute for hyperlinks in printed documentation and help to navigate it. |
Start from new page |
page.start : boolean
This group of parameters specifies which documentation blocks should start from a new page. It has effect only when you generate RTF documentation. |
page.start.toc : boolean
Specify whether the Table Of Contents should start from a new page. See Also: “Generate | Table Of Contents” parameter |
|
page.start.overview : boolean
Specify whether the documentation Overview should start from a new page. See Also: “Generate | Overview” parameter |
|
page.start.overview.allClasses : boolean
Specify whether the All Classes Summary should start from a new page. See Also: “Generate | Overview | All Classes Summary” parameter |
|
page.start.package : boolean
Specify whether each Package Overview should start from a new page. See Also: “Generate | Package Overviews” parameter |
|
page.start.class : boolean
Specify whether each class documentation should started from a new page. See Also: “Generate | Class Detail” parameter |