org - maven javadoc skip

¿Hay una manera de acelerar Javadoc(tarda 7 minutos)

Question

Estoy construyendo un Javadoc para un módulo con 2,509 clases. Esto lleva actualmente 7 min o 6 archivos por segundo.

Yo he tratado

mvn -T 1C install

Sin embargo, javadoc solo usa 1 CPU. ¿Hay alguna forma de usar más y / o acelerar?

Estoy usando Oracle JDK 8 update 112 . Mi máquina dev tiene 16 núcleos y 128 GB de memoria.

Ejecutando el registrador de vuelo puedo ver que solo hay un hilo main

Para aquellos que estén interesados, he usado las siguientes opciones:

<plugin>
    <artifactId>maven-javadoc-plugin</artifactId>
    <configuration>
        <additionalJOptions>
            <additionalJOption>-J-XX:+UnlockCommercialFeatures</additionalJOption>
            <additionalJOption>-J-XX:+FlightRecorder</additionalJOption>
            <additionalJOption>-J-XX:StartFlightRecording=name=test,filename=/tmp/myrecording-50.jfr,dumponexit=true</additionalJOption>
            <additionalJOption>-J-XX:FlightRecorderOptions=loglevel=debug</additionalJOption>
        </additionalJOptions>
    </configuration>
</plugin>

NOTA: una solución es hacer:

-Dmaven.javadoc.skip=true

Answer 1

@lbndev tiene razón, al menos con el Doclet predeterminado ( com.sun.tools.doclets.formats.html.HtmlDoclet ) que se suministra con Javadoc. Una mirada a través de la fuente confirma la implementación de un solo hilo:

• El punto de partida está en la clase padre AbstractDoclet.startGeneration()
• Esto a su vez llama al new ClassTree() que llama a ClassTree.buildTree() que usa un bucle for para iterar la lista de clases, generando modelos de las clases
• El siguiente paso es AbstractDoclet.generateClassFiles() , nuevamente un bucle for en los paquetes
• Esto luego profundiza en HtmlDoclet.generateClassFiles() , que itera package.allClasses() , nuevamente en un bucle for .

(Esos enlaces son a la fuente de JDK 8. Con JDK 11 las clases se han movido, pero la base for bucles en HtmlDoclet y AbstractDoclet todavía están allí).

Algunos perfiles basados ​​en muestras confirmaron que estos son los métodos que constituyen el cuello de botella:

Esto no será lo que espera escuchar, pero parece que no hay ninguna opción en el Javadoc estándar actual para subprocesos múltiples, al menos dentro de un solo módulo de Maven.

generateClassFiles() etc. se prestaría bien para un poco de subprocesamiento múltiple, aunque probablemente esto debería ser un cambio en el JDK. Como se menciona a continuación, AbstractDoclet.isValidDoclet() incluso bloquea activamente la subclasificación de HtmlDoclet . Intentar volver a implementar algunos de esos bucles como un tercero tendría que introducir muchos otros códigos.

Un escaneo alrededor de otras implementaciones de Doclet (por ejemplo, javadown ) solo encontró un estilo de implementación similar alrededor del desglose del paquete y la clase. Es posible que otros en este hilo sepan más.

Pensando un poco más ampliamente, podría haber espacio para sintonizar con DocFileFactory . Está claramente marcado como una clase interna (ni siquiera pública en el paquete), pero sí abstrae la escritura de los archivos (HTML). Parece posible que una versión alternativa de esto podría almacenar el HTML en la memoria, o transmitirlo directamente a un archivo zip, para mejorar el rendimiento de IO. Pero claramente esto también debería comprender el riesgo de cambio en las herramientas JDK.

Answer 2

La ejecución de maven con -T1C hará que maven intente construir módulos en paralelo, por lo que si tiene un proyecto de múltiples módulos, en el mejor de los casos, construirá el javadoc de cada módulo en paralelo (si su gráfica de dependencia entre módulos lo permite).

El proceso javadoc en sí es de un solo subproceso, por lo que no podrá usar múltiples núcleos para generar el javadoc de un solo módulo.

Sin embargo, ya que tiene muchas clases (y posiblemente muchos doclets de enlace o similares), tal vez el proceso javadoc podría beneficiarse de un montón extendido. ¿Has mirado en la actividad de GC? Intente agregar esto en su configuración, vea si ayuda:

<additionalJOption>-J-Xms2g</additionalJOption>
<additionalJOption>-J-Xmx2g</additionalJOption>

Answer 3

La personalización de Maven es una forma de acelerar la generación de javadoc.

Otro enfoque sería cambiar el doclet utilizado para generar el javadoc. El complemento javadoc de Maven le permite cambiar el doclet utilizado para generar el javadoc

https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html

Encontré el siguiente doclet comercial (no estoy afiliado a ellos de ninguna manera) que dice ser más rápido que el javadoc tradicional. Ofrece una licencia gratuita / de prueba / comercial. Si realmente estás ansioso por acelerar tu compilación de javadoc, quizás valga la pena ver si vale la pena el precio.

http://www.filigris.com/docflex-javadoc

Tal vez las alternativas de código abierto existen en internet ...

Answer 4

Puedes hacer que Maven use múltiples hilos por núcleo en todos los núcleos.

Por ejemplo.

mvn -T 4C install # will use 4 threads per available CPU core

Puedes cambiar 4 arriba a cualquier número que quieras. Tienes una máquina con muchos recursos. Intente 8 o 16 .

También has intentado usar javadoc-no-fork ? Esto asegurará que javadoc no se active por segunda vez: https://maven.apache.org/plugins/maven-javadoc-plugin/examples/javadoc-nofork.html

Answer 5

Use doxygen en lugar del mvn regular, lo que está usando ahora.

Answer 6

javadoc, y el doclet estándar, actualmente son fundamentalmente de un solo hilo.

Es "en el radar" mejorar esto, principalmente mediante la generación de páginas en paralelo, pero esto significa adaptar la seguridad MT a varias estructuras de datos compartidas.