neulab/tldr huggingface dataset:
-use Includes one "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. Given class C, things that use class C would include subclasses of C, fields declared as C, methods that return C, and methods and constructors with parameters of type C. For example, let us look at what might appear on the "Use" page for String. The getName() method in the java.awt.Font class returns type String. Therefore, getName() uses String, and you will find that method on the "Use" page for String. Note that this documents only uses of the API, not the implementation. If a method uses String in its implementation but does not take a string as an argument or return a string, that is not considered a "use" of String. You can access the generated "Use" page by first going to the class or package, then clicking on the "Use" link in the navigation bar.
-version Includes the @version text in the generated docs. This text is omitted by default. To tell what version of the Javadoc tool you are using, use the -J-version option.
-author Includes the @author text in the generated docs.
-splitindex Splits the index file into multiple files, alphabetically, one file per letter, plus a file for any index entries that start with non-alphabetical characters.
-windowtitle  title Specifies the title to be placed in the HTML <title> tag. This appears in the window title and in any browser bookmarks (favorite places) that someone creates for this page. This title should not contain any HTML tags, as the browser will not properly interpret them. Any internal quotation marks within title may have to be escaped. If -windowtitle is omitted, the Javadoc tool uses the value of -doctitle for this option. % javadoc -windowtitle "Java SE Platform" com.mypackage
-doctitle  title Specifies the title to be placed near the top of the overview summary file. The title will be placed as a centered, level-one heading directly beneath the upper navigation bar. The title may contain html tags and white space, though if it does, it must be enclosed in quotes. Any internal quotation marks within title may have to be escaped. % javadoc -doctitle "Java(TM)" com.mypackage
-title  title This option no longer exists. It existed only in Beta versions of Javadoc 1.2. It has been renamed to -doctitle. This option is being renamed to make it clear that it defines the document title rather than the window title.
-header  header Specifies the header text to be placed at the top of each output file. The header will be placed to the right of the upper navigation bar. header may contain HTML tags and white space, though if it does, it must be enclosed in quotes. Any internal quotation marks within header may have to be escaped. % javadoc -header "<b>Java 2 Platform </b><br>v1.4" com.mypackage
-footer  footer Specifies the footer text to be placed at the bottom of each output file. The footer will be placed to the right of the lower navigation bar. footer may contain html tags and white space, though if it does, it must be enclosed in quotes. Any internal quotation marks within footer may have to be escaped.
-top Specifies the text to be placed at the top of each output file.
-bottom  text Specifies the text to be placed at the bottom of each output file. The text will be placed at the bottom of the page, below the lower navigation bar. The text may contain HTML tags and white space, though if it does, it must be enclosed in quotes. Any internal quotation marks within text may have to be escaped.
-link  extdocURL Creates links to existing javadoc-generated documentation of external referenced classes. It takes one argument:
o extdocURL is the absolute or relative URL of the directory containing the external javadoc-generated documentation you want to link to. Examples are shown below. The package-list file must be found in this directory (otherwise, use -linkoffline). The Javadoc tool reads the package names from the package-list file and then links to those packages at that URL. When the Javadoc tool is run, the extdocURL value is copied literally into the <A HREF> links that are created. Therefore, extdocURL must be the URL to the directory, not to a file. You can use an absolute link for extdocURL to enable your docs to link to a document on any website, or can use a relative link to link only to a relative location. If relative, the value you pass in should be the relative path from the destination directory (specified with -d) to the directory containing the packages being linked to. When specifying an absolute link you normally use an http: link. However, if you want to link to a file system that has no web server, you can use a file: link -- however, do this only if everyone wanting to access the generated documentation shares the same file system. In all cases, and on all operating systems, you should use a forward slash as the separator, whether the URL is absolute or relative, and "http:" or "file:" based (as specified in the URL Memo @ http://www.ietf.org/rfc/rfc1738.txt).
Absolute http: based link: -link http://<host>/<directory>/<directory>/.../<name>
Absolute file: based link: -link file://<host>/<directory>/<directory>/.../<name>
Relative link: -link <directory>/<directory>/.../<name> You can specify multiple -link options in a given javadoc run to link to multiple documents. Choosing between -linkoffline and -link: Use -link:
o when using a relative path to the external API document, or
o when using an absolute URL to the external API document, if your shell allows a program to open a connection to that URL for reading. Use -linkoffline:
o when using an absolute URL to the external API document, if your shell does not allow a program to open a connection to that URL for reading. This can occur if you are behind a firewall and the document you want to link to is on the other side. Example using absolute links to the external docs - Let us say you want to link to the java.lang, java.io and other Java Platform packages at http://docs.oracle.com/javase/7/docs/api/ @ http://docs.oracle.com/javase/7/docs/api/. The following command generates documentation for the package com.mypackage with links to the Java SE Platform packages. The generated documentation will contain links to the Object class, for example, in the class trees. (Other options, such as -sourcepath and -d, are not shown.) % javadoc -link http://docs.oracle.com/javase/7/docs/api/ com.mypackage Example using relative links to the external docs - Let us say you have two packages whose docs are generated in different runs of the Javadoc tool, and those docs are separated by a relative path. In this example, the packages are com.apipackage, an API, and com.spipackage, an SPI (Service Provide Interface). You want the documentation to reside in docs/api/com/apipackage and docs/spi/com/spipackage. Assuming the API package documentation is already generated, and that docs is the current directory, you would document the SPI package with links to the API documentation by running: % javadoc -d ./spi -link ../api com.spipackage Notice the -link argument is relative to the destination directory (docs/spi). Details - The -link option enables you to link to classes referenced to by your code but not documented in the current javadoc run. For these links to go to valid pages, you must know where those HTML pages are located, and specify that location with extdocURL. This allows, for instance, third party documentation to link to java.* documentation on http://java.sun.com. Omit the -link option for javadoc to create links only to API within the documentation it is generating in the current run. (Without the -link option, the Javadoc tool does not create links to documentation for external references, because it does not know if or where that documentation exists.) This option can create links in several places in the generated documentation. Another use is for cross-links between sets of packages: Execute javadoc on one set of packages, then run javadoc again on another set of packages, creating links both ways between both sets. How a Class Must be Referenced - For a link to an external referenced class to actually appear (and not just its text label), the class must be referenced in the following way. It is not sufficient for it to be referenced in the body of a method. It must be referenced in either an import statement or in a declaration. Here are examples of how the class java.io.File can be referenced:
o In any kind of import statement: by wildcard import, import explicitly by name, or automatically import for java.lang.*. For example, this would suffice: import java.io.*; In 1.3.x and 1.2.x, only an explicit import by name works -- a wildcard import statement does not work, nor does the automatic import java.lang.*.
o In a declaration: void foo(File f) {} The reference and be in the return type or parameter type of a method, constructor, field, class or interface, or in an implements, extends or throws statement. An important corollary is that when you use the -link option, there may be many links that unintentionally do not appear due to this constraint. (The text would appear without a hypertext link.) You can detect these by the warnings they emit. The most innocuous way to properly reference a class and thereby add the link would be to import that class, as shown above. Package List - The -link option requires that a file named package-list, which is generated by the Javadoc tool, exist at the URL you specify with -link. The package-list file is a simple text file that lists the names of packages documented at that location. In the earlier example, the Javadoc tool looks for a file named package-list at the given URL, reads in the package names and then links to those packages at that URL. For example, the package list for the Java SE 6 API is located at http://docs.oracle.com/javase/7/docs/api/package-list @ http://docs.oracle.com/javase/7/docs/api/package-list. and starts as follows: java.applet java.awt java.awt.color java.awt.datatransfer java.awt.dnd java.awt.event java.awt.font etc. When javadoc is run without the -link option, when it encounters a name that belongs to an external referenced class, it prints the name with no link. However, when the -link option is used, the Javadoc tool searches the package-list file at the specified extdocURL location for that package name. If it finds the package name, it prefixes the name with extdocURL. In order for there to be no broken links, all of the documentation for the external references must exist at the specified URLs. The Javadoc tool will not check that these pages exist -- only that the package-list exists. Multiple Links - You can supply multiple -link options to link to any number of external generated documents.   Javadoc 1.2 has a known bug which prevents you from supplying more than one -link command. This was fixed in 1.2.2. Specify a different link option for each external document to link to: % javadoc -link extdocURL1 -link extdocURL2 ... -link extdocURLn com.mypackage where extdocURL1,  extdocURL2,  ... extdocURLn point respectively to the roots of external documents, each of which contains a file named package-list. Cross-links - Note that "bootstrapping" may be required when cross-linking two or more documents that have not previously been generated. In other words, if package-list does not exist for either document, when you run the Javadoc tool on the first document, the package-list will not yet exist for the second document. Therefore, to create the external links, you must re-generate the first document after generating the second document. In this case, the purpose of first generating a document is to create its package-list (or you can create it by hand it if you're certain of the package names). Then generate the second document with its external links. The Javadoc tool prints a warning if a needed external package-list file does not exist.
-linkoffline  extdocURL  packagelistLoc This option is a variation of -link; they both create links to javadoc-generated documentation for external referenced classes. Use the -linkoffline option when linking to a document on the web when the Javadoc tool itself is "offline" -- that is, it cannot access the document through a web connection. More specifically, use -linkoffline if the external document's package-list file is not accessible or does not exist at the extdocURL location but does exist at a different location, which can be specified by packageListLoc (typically local). Thus, if extdocURL is accessible only on the World Wide Web, -linkoffline removes the constraint that the Javadoc tool have a web connection when generating the documentation. Another use is as a "hack" to update docs: After you have run javadoc on a full set of packages, then you can run javadoc again on onlya smaller set of changed packages, so that the updated files can be inserted back into the original set. Examples are given below. The -linkoffline option takes two arguments -- the first for the string to be embedded in the <a href> links, the second telling it where to find package-list:
o extdocURL is the absolute or relative URL of the directory containing the external javadoc-generated documentation you want to link to. If relative, the value should be the relative path from the destination directory (specified with -d) to the root of the packages being linked to. For more details, see extdocURL in the -link option.
-linksource Creates an HTML version of each source file (with line numbers) and adds links to them from the standard HTML documentation. Links are created for classes, interfaces, constructors, methods and fields whose declarations are in a source file. Otherwise, links are not created, such as for default constructors and generated classes. This option exposes all private implementation details in the included source files, including private classes, private fields, and the bodies of private methods, regardless of the -public, -package, -protected and -private options. Unless you also use the -private option, not all private classes or interfaces will necessarily be accessible via links. Each link appears on the name of the identifier in its declaration. For example, the link to the source code of the Button class would be on the word "Button": public class Button extends Component implements Accessible and the link to the source code of the getLabel() method in the Button class would be on the word "getLabel": public String getLabel()
-group  groupheading  packagepattern:packagepattern:... Separates packages on the overview page into whatever groups you specify, one group per table. You specify each group with a different -group option. The groups appear on the page in the order specified on the command line; packages are alphabetized within a group. For a given -group option, the packages matching the list of packagepattern expressions appear in a table with the heading groupheading.
o groupheading can be any text, and can include white space. This text is placed in the table heading for the group.
o packagepattern 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. Multiple patterns can be included in a group by separating them with colons (:). NOTE: If using an asterisk in a pattern or pattern list, the pattern list must be inside quotes, such as "java.lang*:java.util" If you do not supply any -group option, 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". For example, the following option separates the four documented packages into core, extension and other packages. Notice the trailing "dot" does not appear in "java.lang*" -- including the dot, such as "java.lang.*" would omit the java.lang package. % javadoc -group "Core Packages" "java.lang*:java.util" -group "Extension Packages" "javax.*" java.lang java.lang.reflect java.util javax.servlet java.new This results in the groupings:
Core Packages java.lang java.lang.reflect java.util
Extension Packages javax.servlet
Other Packages java.new
-nodeprecated Prevents the generation of any deprecated API at all in the documentation. This does what -nodeprecatedlist does, plus it does not generate any deprecated API throughout the rest of the documentation. This is useful when writing code and you don't want to be distracted by the deprecated code.
-nodeprecatedlist Prevents the generation of the file containing the list of deprecated APIs (deprecated-list.html) and the link in the navigation bar to that page. (However, javadoc continues to generate the deprecated API throughout the rest of the document.) This is useful if your source code contains no deprecated API, and you want to make the navigation bar cleaner.
-nosince Omits from the generated docs the "Since" sections associated with the @since tags.
-notree Omits the class/interface hierarchy pages from the generated docs. These are the pages you reach using the "Tree" button in the navigation bar. The hierarchy is produced by default.
-noindex Omits the index from the generated docs. The index is produced by default.
-nohelp Omits the HELP link in the navigation bars at the top and bottom of each page of output.
-nonavbar Prevents the generation of the navigation bar, header and footer, otherwise found at the top and bottom of the generated pages. Has no affect on the "bottom" option. The -nonavbar option is useful when you are interested only in the content and have no need for navigation, such as converting the files to PostScript or PDF for print only.
-helpfile  path/filename Specifies the path of an alternate help file path/filename that the HELP link in the top and bottom navigation bars link to. Without this option, the Javadoc tool automatically creates a help file help-doc.html that is hard-coded in the Javadoc tool. This option enables you to override this default. The filename can be any name and is not restricted to help-doc.html -- the Javadoc tool will adjust the links in the navigation bar accordingly. For example: % javadoc -helpfile /home/user/myhelp.html java.awt
-stylesheetfile  path/filename Specifies the path of an alternate HTML stylesheet file. Without this option, the Javadoc tool automatically creates a stylesheet file stylesheet.css that is hard-coded in the Javadoc tool. This option enables you to override this default. The filename can be any name and is not restricted to stylesheet.css. For example: % javadoc -stylesheetfile /home/user/mystylesheet.css com.mypackage
-serialwarn Generates compile-time warnings for missing @serial tags. By default, Javadoc 1.2.2 (and later versions) generates no serial warnings. (This is a reversal from earlier versions.) Use this option to display the serial warnings, which helps to properly document default serializable fields and writeExternal methods.
-charset  name Specifies the HTML character set for this document. The name should be a preferred MIME name as given in the IANA Registry @ http://www.iana.org/assignments/character-sets. For example: % javadoc -charset "iso-8859-1" mypackage would insert the following line in the head of every generated page: <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> This META tag is described in the HTML standard @ http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2. (4197265 and 4137321) Also see -encoding and -docencoding.
-docencoding  name Specifies the encoding of the generated HTML files. The name should be a preferred MIME name as given in the IANA Registry @ http://www.iana.org/assignments/character-sets. If you omit this option but use -encoding, then the encoding of the generated HTML files is determined by -encoding. Example: % javadoc -docencoding "ISO-8859-1" mypackage Also see -encoding and -charset.
-keywords Adds HTML meta keyword tags to the generated file for each class. These tags can help the page be found by search engines that look for meta tags. (Most search engines that search the entire Internet do not look at meta tags, because pages can misuse them; but search engines offered by companies that confine their search to their own website can benefit by looking at meta tags.) The meta tags include the fully qualified name of the class and the unqualified names of the fields and methods. Constructors are not included because they are identical to the class name. For example, the class String starts with these keywords: <META NAME="keywords" CONTENT="java.lang.String class"> <META NAME="keywords" CONTENT="CASE_INSENSITIVE_ORDER"> <META NAME="keywords" CONTENT="length()"> <META NAME="keywords" CONTENT="charAt()">
-taglet  class Specifies the class file that starts the taglet used in generating the documentation for that tag. Use the fully-qualified name for class. This taglet also defines the number of text arguments that the custom tag has. The taglet accepts those arguments, processes them, and generates the output. For extensive documentation with example taglets, see:
o Taglet Overview @ http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/taglet/overview.html Taglets are useful for block or inline tags. They can have any number of arguments and implement custom behavior, such as making text bold, formatting bullets, writing out the text to a file, or starting other processes. Taglets can only determine where a tag should appear and in what form. All other decisions are made by the doclet. So a taglet cannot do things such as remove a class name from the list of included classes. However, it can execute side effects, such as printing the tag's text to a file or triggering another process. Use the -tagletpath option to specify the path to the taglet. Here is an example that inserts the "To Do" taglet after "Parameters" and ahead of "Throws" in the generated pages: -taglet com.sun.tools.doclets.ToDoTaglet -tagletpath /home/taglets -tag return -tag param -tag todo -tag throws -tag see Alternatively, you can use the -taglet option in place of its -tag option, but that may be harder to read.
-tagletpath  tagletpathlist Specifies the search paths for finding taglet class files (.class). The tagletpathlist can contain multiple paths by separating them with a colon (:). The Javadoc tool will search in all subdirectories of the specified paths.
-docfilessubdirs Enables deep copying of "doc-files" directories. In other words, subdirectories and all contents are recursively copied to the destination. For example, the directory doc-files/example/images and all its contents would now be copied. There is also an option to exclude subdirectories.
-excludedocfilessubdir  name1:name2... Excludes any "doc-files" subdirectories with the given names. This prevents the copying of SCCS and other source-code-control subdirectories.
-noqualifier  all  |  packagename1:packagename2:... Omits qualifying package name from ahead of class names in output. The argument to -noqualifier is either "all" (all package qualifiers are omitted) or a colon-separate list of packages, with wildcards, to be removed as qualifiers. The package name is removed from places where class or interface names appear. The following example omits all package qualifiers: -noqualifier all The following example omits "java.lang" and "java.io" package qualifiers: -noqualifier java.lang:java.io The following example omits package qualifiers starting with "java", and "com.sun" subpackages (but not "javax"): -noqualifier java.*:com.sun.* Where a package qualifier would appear due to the above behavior, the name can be suitably shortened -- see How a name is displayed. This rule is in effect whether or not -noqualifier is used.
-notimestamp Suppresses the timestamp, which is hidden in an HTML comment in the generated HTML near the top of each page. Useful when you want to run javadoc on two source bases and diff them, as it prevents timestamps from causing a diff (which would otherwise be a diff on every page). The timestamp includes the javadoc version number, and currently looks like this: <!-- Generated by javadoc (build 1.5.0_01) on Thu Apr 02 14:04:52 IST 2009 -->
-nocomment Suppress the entire comment body, including the main description and all tags, generating only declarations. This option enables re-using source files originally intended for a different purpose, to produce skeleton HTML documentation at the early stages of a new project.
-sourcetab tabLength Specify the number of spaces each tab takes up in the source.
To shorten or simplify the javadoc command line, you can specify one or more files that themselves contain arguments to the javadoc command (except -J options). This enables you to create javadoc commands of any length on any operating system.
When executing javadoc, pass in the path and name of each argument file with the '@' leading character. When javadoc encounters an argument beginning with the character `@', it expands the contents of that file into the argument list.
Example - Single Arg File You could use a single argument file named "argfile" to hold all Javadoc arguments: % javadoc @argfile
Example - Two Arg Files You can create two argument files -- one for the Javadoc options and the other for the package names or source filenames: (Notice the following lists have no line-continuation characters.)
Create a file named "options" containing: -d docs-filelist -use -splitindex -windowtitle 'Java SE 7 API Specification' -doctitle 'Java SE 7 API Specification' -header '<b>Java(TM) SE 7</b>' -bottom 'Copyright &copy; 1993-2011 Oracle and/or its affiliates. All rights reserved.' -group "Core Packages" "java.*" -overview /java/pubs/ws/1.7.0/src/share/classes/overview-core.html -sourcepath /java/pubs/ws/1.7.0/src/share/classes
Create a file named "packages" containing: com.mypackage1 com.mypackage2 com.mypackage3
You would then run javadoc with: % javadoc @options @packages
Example - Arg Files with Paths The argument files can have paths, but any filenames inside the files are relative to the current working directory (not path1 or path2): % javadoc @path1/options @path2/packages
Example - Option Arguments Here's an example of saving just an argument to a javadoc option in an argument file. We'll use the -bottom option, since it can have a lengthy argument. You could create a file named "bottom" containing its text argument: <font size="-1"> <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/> Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/> Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.</font>
Then run the Javadoc tool with: % javadoc -bottom @bottom @packages
Or you could include the -bottom option at the start of the argument file, and then just run it as: % javadoc @bottom @packages
Name Running
Version Numbers - The version number of javadoc can be determined using javadoc -J-version. The version number of the standard doclet appears in its output stream. It can be turned off with -quiet.
Public programmatic interface - To invoke the Javadoc tool from within programs written in the Java language. This interface is in com.sun.tools.javadoc.Main (and javadoc is re-entrant). For more details, see Standard Doclet @ http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/standard-doclet.html#runningprogrammatically.
Running Doclets - The instructions given below are for invoking the standard HTML doclet. To invoke a custom doclet, use the -doclet and -docletpath options. For full, working examples of running a particular doclet, see the MIF Doclet documentation @ http://java.sun.com/j2se/javadoc/mifdoclet/docs/mifdoclet.html.
You can run javadoc on entire packages or individual source files. Each package name has a corresponding directory name. In the following examples, the source files are located at /home/src/java/awt/*.java. The destination directory is /home/html.
Documenting One or More Packages To document a package, the source files (*.java) for that package must be located in a directory having the same name as the package. If a package name is made up of several identifiers (separated by dots, such as java.awt.color), each subsequent identifier must correspond to a deeper subdirectory (such as java/awt/color). You may split the source files for a single package among two such directory trees located at different places, as long as -sourcepath points to them both -- for example src1/java/awt/color and src2/java/awt/color.
You can run javadoc either by changing directories (with cd) or by using -sourcepath option. The examples below illustrate both alternatives.
o Case 1 - Run recursively starting from one or more packages - This example uses -sourcepath so javadoc can be run from any directory and -subpackages (a new 1.4 option) for recursion. It traverses the subpackages of the java directory excluding packages rooted at java.net and java.lang. Notice this excludes java.lang.ref, a subpackage of java.lang). % javadoc -d /home/html -sourcepath /home/src -subpackages java -exclude java.net:java.lang
To also traverse down other package trees, append their names to the -subpackages argument, such as java:javax:org.xml.sax.
o Case 2 - Run on explicit packages after changing to the "root" source directory - Change to the parent directory of the fully-qualified package. Then run javadoc, supplying names of one or more packages you want to document: % cd /home/src/ % javadoc -d /home/html java.awt java.awt.event
o Case 3 - Run from any directory on explicit packages in a single directory tree - In this case, it doesn't matter what the current directory is. Run javadoc supplying -sourcepath with the parent directory of the top-level package, and supplying names of one or more packages you want to document: % javadoc -d /home/html -sourcepath /home/src java.awt java.awt.event
o Case 4 - Run from any directory on explicit packages in multiple directory trees - This is the same as case 3, but for packages in separate directory trees. Run javadoc supplying -sourcepath with the path to each tree's root (colon-separated) and supply names of one or more packages you want to document. All source files for a given package do not need to be located under a single root directory -- they just need to be found somewhere along the sourcepath. % javadoc -d /home/html -sourcepath /home/src1:/home/src2 java.awt java.awt.event
Result: All cases generate HTML-formatted documentation for the public and protected classes and interfaces in packages java.awt and java.awt.event and save the HTML files in the specified destination directory (/home/html). Because two or more packages are being generated, the document has three HTML frames -- for the list of packages, the list of classes, and the main class pages.
Documenting One or More Classes The second way to run the Javadoc tool is by passing in one or more source files (.java). You can run javadoc either of the following two ways -- by changing directories (with cd) or by fully-specifying the path to the .java files. Relative paths are relative to the current directory. The -sourcepath option is ignored when passing in source files. You can use command line wildcards, such as asterisk (*), to specify groups of classes.
o Case 1 - Changing to the source directory - Change to the directory holding the .java files. Then run javadoc, supplying names of one or more source files you want to document. % cd /home/src/java/awt % javadoc -d /home/html Button.java Canvas.java Graphics*.java This example generates HTML-formatted documentation for the classes Button, Canvas and classes beginning with Graphics. Because source files rather than package names were passed in as arguments to javadoc, the document has two frames -- for the list of classes and the main page.
o Case 2 - Changing to the package root directory - This is useful for documenting individual source files from different subpackages off the same root. Change to the package root directory, and supply the source files with paths from the root. % cd /home/src/ % javadoc -d /home/html java/awt/Button.java java/applet/Applet.java This example generates HTML-formatted documentation for the classes Button and Applet.
o Case 3 - From any directory - In this case, it doesn't matter what the current directory is. Run javadoc supplying the absolute path (or path relative to the current directory) to the .java files you want to document. % javadoc -d /home/html /home/src/java/awt/Button.java /home/src/java/awt/Graphics*.java This example generates HTML-formatted documentation for the class Button and classes beginning with Graphics.
Documenting Both Packages and Classes You can document entire packages and individual classes at the same time. Here's an example that mixes two of the previous examples. You can use -sourcepath for the path to the packages but not for the path to the individual classes. % javadoc -d /home/html -sourcepath /home/src java.awt /home/src/java/applet/Applet.java
This example generates HTML-formatted documentation for the package java.awt and class Applet. (The Javadoc tool determines the package name for Applet from the package declaration, if any, in the Applet.java source file.)
The Javadoc tool has many useful options, some of which are more commonly used than others. Here is effectively the command we use to run the Javadoc tool on the Java platform API. We use 180MB of memory to generate the documentation for the 1500 (approx.) public and protected classes in the Java SE Platform, Standard Edition, v1.2.
The same example is shown twice -- first as executed on the command line, then as executed from a makefile. It uses absolute paths in the option arguments, which enables the same javadoc command to be run from any directory.
Command Line Example The following example may be too long for some shells such as DOS. You can use a command line argument file (or write a shell script) to workaround this limitation. % javadoc -sourcepath /java/jdk/src/share/classes \ -overview /java/jdk/src/share/classes/overview.html \ -d /java/jdk/build/api \ -use \ -splitIndex \ -windowtitle 'Java Platform, Standard Edition 7 API Specification' \ -doctitle 'Java Platform, Standard Edition 7 API Specification' \ -header '<b>Java(TM) SE 7</b>' \ -bottom '<font size="-1"> <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/> Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/> Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.</font>' \ -group "Core Packages" "java.*:com.sun.java.*:org.omg.*" \ -group "Extension Packages" "javax.*" \ -J-Xmx180m \ @packages
where packages is the name of a file containing the packages to process, such as java.applet java.lang. None of the options should contain any newline characters between the single quotes. (For example, if you copy and paste this example, delete the newline characters from the -bottom option.) See the other notes listed below.
Makefile Example This is an example of a GNU makefile. For an example of a Windows makefile, see creating a makefile for Windows @ http://java.sun.com/j2se/javadoc/faq/index.html#makefiles. javadoc -sourcepath $(SRCDIR)              \   /* Sets path for source files     */ -overview $(SRCDIR)/overview.html  \   /* Sets file for overview text    */ -d /java/jdk/build/api             \   /* Sets destination directory     */ -use                               \   /* Adds "Use" files               */ -splitIndex                        \   /* Splits index A-Z               */ -windowtitle $(WINDOWTITLE)        \   /* Adds a window title            */ -doctitle $(DOCTITLE)              \   /* Adds a doc title               */ -header $(HEADER)                  \   /* Adds running header text       */ -bottom $(BOTTOM)                  \   /* Adds text at bottom            */ -group $(GROUPCORE)                \   /* 1st subhead on overview page   */ -group $(GROUPEXT)                 \   /* 2nd subhead on overview page   */ -J-Xmx180m                         \   /* Sets memory to 180MB           */ java.lang java.lang.reflect        \   /* Sets packages to document      */ java.util java.io java.net         \ java.applet
WINDOWTITLE = 'Java(TM) SE 7 API Specification' DOCTITLE = 'Java(TM) Platform Standard Edition 7 API Specification' HEADER = '<b>Java(TM) SE 7</font>' BOTTOM = '<font size="-1"> <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/> Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/> Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.</font>' GROUPCORE = '"Core Packages" "java.*:com.sun.java.*:org.omg.*"' GROUPEXT  = '"Extension Packages" "javax.*"' SRCDIR = '/java/jdk/1.7.0/src/share/classes'
Single quotes are used to surround makefile arguments.
o If you omit the -windowtitle option, the Javadoc tool copies the doc title to the window title. The -windowtitle text is basically the same as the -doctitle but without HTML tags, to prevent those tags from appearing as raw text in the window title.
o If you omit the -footer option, as done here, the Javadoc tool copies the header text to the footer.
o Other important options you might want to use but not needed in this example are -classpath and -link.
General Troubleshooting o Javadoc FAQ - Commonly-encountered bugs and troubleshooting tips can be found on the Javadoc FAQ @ http://java.sun.com/j2se/javadoc/faq/index.html#B
o Bugs and Limitations - You can also see some bugs listed at Important Bug Fixes and Changes.
o Version number - See version numbers.
o Documents only legal classes - When documenting a package, javadoc only reads files whose names are composed of legal class names. You can prevent javadoc from parsing a file by including, for example, a hyphen "-" in its filename.
Errors and Warnings Error and warning messages contain the filename and line number to the declaration line rather than to the particular line in the doc comment.
o "error: cannot read: Class1.java" the Javadoc tool is trying to load the class Class1.java in the current directory. The class name is shown with its path (absolute or relative), which in this case is the same as ./Class1.java.
CLASSPATH Environment variable that provides the path which javadoc uses to find user class files. This environment variable is overridden by the -classpath option. Separate directories with a colon, for example:
o java(1)
o javap(1)
o Javadoc Home Page @ http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html
o How to Write Doc Comments for Javadoc @ http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
o Setting the Class Path @ http://docs.oracle.com/javase/7/docs/technotes/tools/index.html#general
o How Javac and Javadoc Find Classes @ http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html#srcfiles (tools.jar)
BINWALK(1)                        User Commands                       BINWALK(1)
binwalk - tool for searching binary images for embedded files and executable code
binwalk [OPTIONS] [FILE1] [FILE2] [FILE3] ...
Binwalk v2.1.1 Craig Heffner, http://www.binwalk.org
Signature Scan Options: -B, --signature Scan target file(s) for common file signatures
-R, --raw=<str> Scan target file(s) for the specified sequence of bytes
-A, --opcodes Scan target file(s) for common executable opcode signatures
-m, --magic=<file> Specify a custom magic file to use
-b, --dumb Disable smart signature keywords
-I, --invalid Show results marked as invalid
-x, --exclude=<str> Exclude results that match <str>
-y, --include=<str> Only show results that match <str>
Extraction Options: -e, --extract Automatically extract known file types
-D, --dd=<type:ext:cmd> Extract <type> signatures, give the files an extension of <ext>, and execute <cmd>
-M, --matryoshka Recursively scan extracted files
-d, --depth=<int> Limit matryoshka recursion depth (default: 8 levels deep)
-C, --directory=<str> Extract files/folders to a custom directory (default: current working directory)
-j, --size=<int> Limit the size of each extracted file
-n, --count=<int> Limit the number of extracted files
-r, --rm Delete carved files after extraction
-z, --carve Carve data from files, but don't execute extraction utilities
Entropy Analysis Options: -E, --entropy Calculate file entropy
-F, --fast Use faster, but less detailed, entropy analysis
-J, --save Save plot as a PNG
-Q, --nlegend Omit the legend from the entropy plot graph
-N, --nplot Do not generate an entropy plot graph
-H, --high=<float> Set the rising edge entropy trigger threshold (default: 0.95)
-L, --low=<float> Set the falling edge entropy trigger threshold (default: 0.85)
Binary Diffing Options: -W, --hexdump Perform a hexdump / diff of a file or files
-G, --green Only show lines containing bytes that are the same among all files
-i, --red Only show lines containing bytes that are different among all files
-U, --blue Only show lines containing bytes that are different among some files
-w, --terse Diff all files, but only display a hex dump of the first file
Raw Compression Options: -X, --deflate Scan for raw deflate compression streams
-Z, --lzma Scan for raw LZMA compression streams
-P, --partial Perform a superficial, but faster, scan
-S, --stop Stop after the first result
General Options: -l, --length=<int> Number of bytes to scan
-o, --offset=<int> Start scan at this file offset
-O, --base=<int> Add a base address to all printed offsets
-K, --block=<int> Set file block size
-g, --swap=<int> Reverse every n bytes before scanning
-f, --log=<file> Log results to file
-c, --csv Log results to file in CSV format
-t, --term Format output to fit the terminal window
-q, --quiet Suppress output to stdout
-v, --verbose Enable verbose output
-h, --help Show help output
-a, --finclude=<str> Only scan files whose names match this regex
-p, --fexclude=<str> Do not scan files whose names match this regex
-s, --status=<int> Enable the status server on the specified port
GIT-LS-REMOTE(1)                   Git Manual                   GIT-LS-REMOTE(1)
git-ls-remote - List references in a remote repository
git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>] [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] [--symref] [<repository> [<refs>...]]
Displays references available in a remote repository along with the associated commit IDs.
-h, --heads, -t, --tags Limit to only refs/heads and refs/tags, respectively. These options are not mutually exclusive; when given both, references stored in refs/heads and refs/tags are displayed. Note that git ls-remote -h used without anything else on the command line gives help, consistent with other git subcommands.
--refs Do not show peeled tags or pseudorefs like HEAD in the output.
-q, --quiet Do not print remote URL to stderr.
--upload-pack=<exec> Specify the full path of git-upload-pack on the remote host. This allows listing references from repositories accessed via SSH and where the SSH daemon does not use the PATH configured by the user.
--exit-code Exit with status "2" when no matching refs are found in the remote repository. Usually the command exits with status "0" to indicate it successfully talked with the remote repository, whether it found any matching refs.
--get-url Expand the URL of the given remote repository taking into account any "url.<base>.insteadOf" config setting (See git-config(1)) and exit without talking to the remote.
--symref In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref. Currently, upload-pack only shows the symref HEAD, so it will be the only one shown by ls-remote.
--sort=<key> Sort based on the key given. Prefix - to sort in descending order of the value. Supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable. See git- for-each-ref(1) for more sort options, but be aware keys like committerdate that require access to the objects themselves will not work for refs whose objects have not yet been fetched from the remote, and will give a missing object error.
-o <option>, --server-option=<option> Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. When multiple --server-option=<option> are given, they are all sent to the other side in the order listed on the command line.
<repository> The "remote" repository to query. This parameter can be either a URL or the name of a remote (see the GIT URLS and REMOTES sections of git-fetch(1)).
<refs>... When unspecified, all references, after filtering done with --heads and --tags, are shown. When <refs>... are specified, only references matching the given patterns are displayed.
$ git ls-remote --tags ./. d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3 c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2 0918385dbd9656cab0d1d81ba7453d49bbc16250        refs/tags/junio-gpg-pub $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc 5fe978a5381f1fbad26a80e682ddd2a401966740        refs/heads/master c781a84b5204fb294c9ccc79f8b3baceeb32c061        refs/heads/seen $ git remote add korg http://www.kernel.org/pub/scm/git/git.git $ git ls-remote --tags korg v\* d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3
git-check-ref-format(1).
PLANTUML(1)                  General Commands Manual                 PLANTUML(1)
plantuml - program to generate UML diagram from a text description
plantuml [options] files/dirs...
PlantUML is used to draw UML diagram, using a simple and human readable text description.
Notice that graphviz is required to be installed for generation of all diagrams but sequence diagrams.
When files/directories are given, they are processed in batch mode. Otherwise GUI window appears. It allows user to browse directories and view diagrams generated from suitable files (must have one of the following extensions: .txt, .tex, .java, .htm, .html, .c, .h, .cpp).
You can use the following wildcards in files/dirs:
*      means any characters but '/'
?      one and only one character but '/'
**     means any characters (used to recurse through directories)
-tsvg  Generate images using SVG format.
-output dir, -o dir Generate images in the specified directory.
-config file Read the provided config file before each diagram.
-charset xxx Use a specific charset (default is UTF-8).
-exclude pattern, -x pattern Exclude files that match the provided pattern.
-metadata Retrieve PlantUML sources from PNG images.
-version Display information about PlantUML and Java versions.
-verbose, -v Have log information.
-keepfiles NOT delete temporary files after process.
-help, -h Display help message.
-testdot Test the installation of graphviz.
-graphvizdot path Specify dot path.
-pipe, -p Use stdin for PlantUML source and stdout for PNG/SVG generation.
-computeurl Compute the encoded URL of a PlantUML source file.
-decodeurl Retrieve the PlantUML source from an encoded URL.
graphviz(1).
PlantUML was written by Arnaud Roques <plantuml@gmail.com>.
This manual page was written by Ilya Paramonov <ivparamonov@gmail.com>, for the Debian project (and may be used by others).
DJANGO-ADMIN(1)                      Django                      DJANGO-ADMIN(1)
django-admin - Utility script for the Django Web framework
django-admin is Django's command-line utility for administrative tasks. This document outlines all it can do.
In addition, manage.py is automatically created in each Django project. manage.py does the same thing as django-admin but takes care of a few things for you:
• It puts your project's package on sys.path.
• It sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project's settings.py file.