> On Mar 30, 2017, at 6:05 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > As a part of JEP 299, we should build the Javadoc as a single combined > output, instead of a dozen or so individual javadoc bundles. This bug fixes > this. The selection on what to include is now based on modules instead of > packages. > > The fix in MakeBase.gmk is to keep CacheFind quiet if the src dir(s) does not > exist, otherwise find can emit an error message. (This was provoked by the > new call to SetupZipArchive). > > The module selection has been contributed by Mandy Chang. > > I intend to push this to JDK9. Since this is a noreg-doc bug, no special RDP2 > process is required. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172312 > <https://bugs.openjdk.java.net/browse/JDK-8172312> > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.01 > <http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.01>
make/common/Modules.gmk I should have cleaned this up in the sandbox and I will leave it for you if you don’t mind. 141 # 142 # Workaround --expand-requires transitive that does not include java.base 143 # 144 DOCS_MODULES += \ 145 java.base \ https://bugs.openjdk.java.net/browse/JDK-8176481 has been fixed. This can be removed now. It’d be good to add a comment something like this. # DOCS_MODULES defines the root modules for javadoc generation. # All of their `require transitive` modules directly and indirectly will be included. I will file an issue to follow up the platform-specific modules. Can you remove 125 DOCS_MODULES += jdk.crypto.mscapi 130 DOCS_MODULES += jdk.crypto.ucrypto make/Javadoc.gmk 224 REFERENCE_TARGET_DIR := $(SUPPORT_OUTPUTDIR)/javase-api I suggest to name the javadoc output directory as “javase-docs/api” in the same layout as described in JEP 299. It may copy the specs under javase-docs/specs directory in the future. 239 --module $(call CommaList, java.base java.se.ee)) java.base can be removed since JDK-8176481 has been resolved. Mandy
