On 02/26/2016 03:49 AM, Jiri Vanek wrote:
On 02/25/2016 06:34 PM, Jonathan Gibbons wrote:
On 02/25/2016 09:23 AM, Jiri Vanek wrote:
I must be missing something. Dozens? Of varius runs of javadoc?
I thought that javadoc ending at the end in single drectory is one
single javadoc for java. If
you are referring to javadoc generated by "per module" then one
jjoined zip is enough for me.
Jiri,
If you accept the premise that javadoc writes one stylesheet.css
file per run of javadoc, take a
look at the following list:
Then my goal will be to crate a trget, which takes
build/linux-x86_64-normal-server-release/images/docs/
and pack it to
build/linux-x86_64-normal-server-release/images/javadoc.zip
It should contains also the "smaller api" you are mentioning below? If
not, then those should appear in this zip too.
$ find build/linux-x86_64-normal-server-release/images/docs/ -name
stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css
The "main"/"Java SE" javadoc bundle that most are aware of is the
shortest filename, in the middle
of the list, but there are lots of other smaller APIs that get their
own doc bundle. You can get at
most of them in released doc sets through the top-level "brick wall"
page, or by using your favorite
search engine.
Hmm.. Do you have some? javadoc offline search is quite painful
think. (Even with new search in 9, which seems to have some troubles
on local filesystem). The best search engine I know is (unluckily)
https://github.com/judovana/JavadocOfflineSearch
The point of the preceding list was to say that each directory
containing stylesheet.css is the root of a separate, distinct, javadoc
bundle. So the smaller APIs that get their own bundle are precisely the
ones given in the preceding list, other than the main javadoc bundle.
The point of the comment about the brick wall and search engines was to
indicate how most people will find these doc bundles in normal use, when
they don't have a cheat sheet like the list above.
As far as IDEs wanting to access javadoc bundles, I would expect that to
make all the docs available, you would want to zip up *each* directory
containing stylesheet.css given in the preceding list. If you just zip
up the top API directory, sure, that will include all the files, but the
reality is that the IDE will likely not have any way of knowing about
the minor doc bundles in all jre/ and jdk/ directories and subdirectories.
-- Jon
--
Thanx a lot!
J.
