Since POMs 31 & BUILD-200, any module specifying a custom doclet will fail to build on Java 6, on OS X.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:javadoc (default-cli) on project custom-doclet-module-jdk6: An error has occurred in JavaDocs report generation: Unable to resolve artifact:groupId = 'org.asciidoctor'
[ERROR] artifactId = 'asciidoclet'
[ERROR] version = '1.5.2': Missing:
[ERROR] ----------
[ERROR] 1) com.sun.tools:tools:jar:1.6.0_65

Multiple factors combined, trying to summarize:

1. parent POMs 31 configure the asciidoclet docletArtifact (singular)—this is only used by the javadoc plugin when the doclet is not empty. Empty means "use the standard doclet".
2. Magnolia Templating JSP specifies a custom doclet (non-empty) for TLD doc generation. This one however configures multiple artifacts, using docletArtifacts (plural)—thus not overriding the asciidoclet single docletArtifact. As a result, any module not overriding the singular docletArtifact will fetch the asciidoclet artifacts (even if it doesn't intend to use it).
3. asciidoclet has a dependency to the com.sun tools jar (with a systemPath relative to java.home). Some say this is unnecessary with Maven anyways.
4. Works everywhere except on Apple JDK 6, where the tools jar is concatenated into the classes jar (as hinted from the spring guys here)

Soooo, all in all we have made zero move towards Asciidoclet in the past months, and I would personally favor the Markdown-based alternative (Pegdown Doclet).

A. Either we find a profile/property configuration to selectively request the asciidoclet artifact for a module which wants to use it (and we can do the similar thing for pegdown).
B. Or we acknowledge it's too early to generalize this config on parent pom level, and leave it down to modules to configure the javadoc plugin. We may still integrate back to parent POMs if adoption comes.