ohair@478: ohair@478: ohair@478: ohair@478: Doc Process Notes ohair@478: ohair@478: ohair@478: ohair@478: ohair@478:


ohair@478: REGEXP

ohair@478:

REGEXP is a list of wildcard patterns that determines which packages listed ohair@478: in CORE_PKGS.gmk go into which summary-table on the main API index page. It ohair@478: was motivated by the need to divide the world into "core packages" ohair@478: (java.*) and "extension packages" (javax.*). In time, the distinction ohair@478: went away. The whole table is now called "Platform Packages"--which ohair@478: eliminated the need for this list of regular expressions. But it lingered on, ohair@478: accreting all of the packages in the JVM, one by one. I pruned it back to "*", ohair@478: so it now covers every package in the Java platform API docs. If some separation ohair@478: is needed in the future, it can grow back into a colon-separated list, starting ohair@478: with this, which is in all respects equivalent to "*" at this point ohair@478: in time:

ohair@478:
ohair@478:
REGEXP = "java.*:javax.*:org.ietf*:org.omg.
ohair@478:
ohair@478:


ohair@478: Release Targets

ohair@478:

(Thanks to Kelly O'Hair for this info.)

ohair@478:

The rel-coredocs and rel-docs targets were added by Eric ohair@478: Armstrong. rel-coredocs assumes the kind of large, 32-bit machine used ohair@478: in the javapubs group's docs-release process. It specifies memory settings accordingly ohair@478: to maximize performance.

ohair@478:

The performance settings, like the sanity check, are most important for the ohair@478: core docs--the platform APIs. Running javadoc on those APIs takes a significant ohair@478: amount of time and memory. Setting the initial heap size as large as possible ohair@478: is important to prevent thrashing as the heap grows. Setting the maximum as ohair@478: large as necessary is also important to keep the job from failing.

ohair@478:
ohair@478:

-J-Xmx512 sets a maximum of 512, which became necessary in 6.0
ohair@478: -J-Xms256 sets starting size to 256 (default is 8)

ohair@478:
ohair@478:

rel-coredocs also includes a sanity check to help ensure that BUILD_NUMBER ohair@478: and MILESTONE are specified properly when docs are built outside of ohair@478: the normal release engineering process, with the intention of releasing them ohair@478: on the web or in a downloaded docs bundle. (When invoked in release engineering's ohair@478: control build, the values are always set properly. But when the targets are ohair@478: run by themselves, they default to b00 and "internal"--which silently ohair@478: sabotage the result of a build that can take many hours to complete.

ohair@478: ohair@478: