Desde que uso Maven, he podido construir e instalar en mis proyectos de repositorio locales que tienen etiquetas Javadoc incompletas (por ejemplo, un parámetro faltante).
Sin embargo, desde que migré a Java 8 (1.8.0-ea-b90) Maven es absolutamente estricto con las etiquetas de documentación faltantes y me muestra muchos errores de Javadoc relacionados con problemas de Javadoc cuando intento construir o instalar un proyecto donde el Javadoc no es "Perfecto". Algunos de los proyectos que estoy tratando de compilar e instalar en mi repositorio local son proyectos de terceros desde los cuales no tengo control. Por lo tanto, la solución de solo arreglar todos los Javadocs en todos estos proyectos no parece ser factible en mi escenario.
Esta es una pequeña parte de la salida que veo cuando ejecuto mvn clean package install
mi proyecto:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.026s
[INFO] Finished at: Mon Apr 08 21:06:17 CEST 2013
[INFO] Final Memory: 27M/437M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:jar (attach-javadocs) on project jpc: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - /Users/sergioc/Documents/workspaces/heal/jpc/src/main/java/org/jpc/engine/prolog/PrologDatabase.java:10: error: @param name not found
[ERROR] * @param terms the terms to assert
[ERROR] ^
[ERROR] /Users/sergioc/Documents/workspaces/heal/jpc/src/main/java/org/jpc/engine/prolog/PrologDatabase.java:11: warning: no description for @return
[ERROR] * @return
[ERROR] ^
El complemento Javadoc Maven está configurado de esta manera en mi POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Como dije antes, todo funciona bien si vuelvo a Java 7. ¿Tal vez es un error relacionado con Maven ejecutándose en Java 8? ¿Cómo podría hacer que funcione (es decir, poder construir el Javadoc del proyecto e instalar su código en mi repositorio local) con Java 8? He probado con Maven 3.0.3 y 3.0.5 en OSX.
ACTUALIZAR:
Si cambio la configuración de mi complemento Javadoc con <failOnError>false</failOnError>
(gracias Martin):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Luego, el proyecto se instala en mi repositorio local. Sin embargo, el Javadoc JAR todavía no se genera.
Un fragmento de la salida que veo en la consola con esta nueva configuración es:
[ERROR] MavenReportException: Error al crear el archivo: Código de salida: 1 - /Users/....java:18: advertencia: no @param ... La línea de comando era: / Library / Java / Home / bin / javadoc @options @paquetes
Consulte los archivos Javadoc generados en '/ Users / sergioc / Documents / workspaces / heal / minitoolbox / target / apidocs' dir.
en org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeJavadocCommandLine (AbstractJavadocMojo.java:5043) en org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport (AbstractJavadocMoche.java.:ava.:ava.:ava.:ava.parte.ma.ma.ma.vava.javac. .javadoc.JavadocJar.execute (JavadocJar.java:181) en org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:101) en org.apache.maven.lifecycle.internal.MojoExecutorejecute.mo. : 209) en org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:153) en org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:145) en org.apache. maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:84) en org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:59) en org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild (LifecycleStarter.java:183) en org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.ja) en org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:320) en org.apache.maven.DefaultMaven.execute (DefaultMaven.java:156) en org.apache.maven.cli.MavenCli.execute (MavenCli.java : 537) en org.apache.maven.cli.MavenCli.doMain (MavenCli.java:196) en org.apache.maven.cli.MavenCli.main (MavenCli.java:141) en sun.reflect.NativeMethodAccessorImpl.invoke0 ( Método nativo) en sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57) en sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) en java.lang.reflect.Method.invoque (Method.java:491) en org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:290) en org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:230) en org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:409) en org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:352)
¿Alguna solución sobre cómo construir las fuentes, instalar el proyecto y generar el Javadoc JAR en un solo paso, ya que funcionaba con Java 7?
Respuestas:
La mejor solución sería corregir los errores de javadoc. Si por alguna razón eso no es posible (es decir: código fuente generado automáticamente), entonces puede deshabilitar esta verificación.
DocLint es una nueva característica en Java 8 , que se resume como:
Esto está habilitado de manera predeterminada y ejecutará muchas comprobaciones antes de generar Javadocs. Debe desactivar esto para Java 8 como se especifica en este hilo . Tendrá que agregar esto a su configuración de Maven:
Para maven-javadoc-plugin 3.0.0+: Reemplazar
con
fuente
javadoc
no conoce esta opción.<doclint>none</doclint>
. Ver maven.apache.org/plugins/maven-javadoc-plugin/…<additionalparam/>
se reemplaza por<additionalOptions/>
. Ver issues.apache.org/jira/browse/MJAVADOC-475El enfoque más fácil para que las cosas funcionen tanto con java 8 como con java 7 es usar un perfil en la compilación:
fuente
Esta es la forma más concisa que conozco para ignorar las advertencias de doclint independientemente de la versión de Java utilizada. No es necesario duplicar la configuración del complemento en varios perfiles con ligeras modificaciones.
Probado en oracle / open jdk 6, 7, 8 y 11.
fuente
build
yprofiles
son bloques de nivel superior en mavenpom.xml
. maven.apache.org/pom.html#Build .Agregue a la sección de propiedades globales en el archivo pom:
La solución común proporcionada aquí en las otras respuestas (agregando esa propiedad en la sección de complementos) no funcionó por alguna razón. Solo configurándolo globalmente pude construir el jar javadoc con éxito.
fuente
La solución más corta que funcionará con cualquier versión de Java:
Solo agrégalo a tu POM y listo.
Esta es básicamente la respuesta de @ ankon más la respuesta de @ zapp .
Para usuarios de maven-javadoc-plugin 3.0.0:
Reemplazar
<additionalparam>-Xdoclint:none</additionalparam>
por
<doclint>none</doclint>
fuente
<additionalJOption>-Xdoclint:none</additionalJOption>
o<doclint>none</doclint>
propiedad a su<properties>
<doclint>none</doclint>
(sin activación basada en la versión JDK), todavía fallará en JDK menos de 1.8, o maven-javadoc-plugin detecta automáticamente si Ladoclint
opción es compatible con la versión actual de Java?No creo que apagar DocLint sea una buena solución, al menos no a largo plazo. Es bueno que Javadoc se haya vuelto un poco más estricto, por lo que la forma correcta de solucionar el problema de compilación es solucionar el problema subyacente . Sí, en última instancia, deberá corregir esos archivos de código fuente.
Estas son las cosas a tener en cuenta que anteriormente podría salirse con la suya:
{@link }
s. (Lo mismo ocurre con etiquetas similares como@see
)@author
Valores inválidos . Esto solía ser aceptado:@author John <[email protected]>
pero ya no es así debido a los corchetes sin escape.Simplemente tendrá que arreglar sus archivos de código fuente y seguir construyendo su Javadoc hasta que pueda compilarse sin fallas. Es engorroso sí, pero personalmente me gusta cuando he llevado mis proyectos al nivel de DocLint porque significa que puedo estar más seguro de que el Javadoc que produzco es en realidad lo que pretendo.
Por supuesto, existe el problema si está generando Javadoc en algún código fuente que no haya producido usted mismo, por ejemplo, porque proviene de algún generador de código, por ejemplo, wsimport . Es extraño que Oracle no haya preparado sus propias herramientas para el cumplimiento de JDK8 antes de lanzar JDK8. Parece que no se solucionará hasta Java 9 . Solo en este caso particular sugiero desactivar DocLint como se documenta en otra parte de esta página.
fuente
wsimport
para formar parte del Javadoc.Primordial
maven-javadoc-plugin
configuración solamente, no soluciona el problema conmvn site
(utilizado, por ejemplo, durante la etapa de lanzamiento). Esto es lo que tuve que hacer:fuente
maven-javadoc-plugin
a través de la<reportPlugins>
sección de lamaven-site-plugin
se no se recomienda para las versiones recientes de Maven 3.Puede intentar configurar la
failOnError
propiedad (consulte la documentación del complemento ) parafalse
:Como puede ver en los documentos, el valor predeterminado es
true
.fuente
Dado que depende de la versión de su JRE que se utiliza para ejecutar el comando maven, es probable que no desee deshabilitar
DocLint
por defecto en su pom.xmlPor lo tanto, desde la línea de comandos puede usar el interruptor
-Dadditionalparam=-Xdoclint:none
.Ejemplo:
mvn clean install -Dadditionalparam=-Xdoclint:none
fuente
-Dadditionalparam=-Xdoclint:none
y todas sus compilaciones funcionarán con Java 8.mvn org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:jar -DadditionalJOption=-Xdoclint:none
- funcionó para míEl nombre de la propiedad de configuración se ha cambiado en la última versión de maven-javadoc-plugin que es 3.0.0.
Por lo tanto, el <additionalparam> no funcionará. Entonces tenemos que modificarlo como se muestra a continuación.
fuente
doclint
documentación aquí: maven.apache.org/plugins/maven-javadoc-plugin/…pom.xml
en el directorio src / build del proyecto. En mi caso, todo lo que tenía que hacer era buscarmaven-javadoc-plugin
y luego ir al<configuration></configuration>
bloque ya presente y agregar<doclint>none</doclint>
. Tan fácil como todo esto es una vez que se sabe, el contexto aquí es que estoy tratando de corregir un error diferente en OpenGrok y nunca he usado Maven antes y no quiero tener que recurrir a otro subproyecto solo para tener que pensar cómo aplicar soluciones rápidasMe gustaría agregar una idea de otras respuestas
En mi caso
No funcionó
Comencemos con eso, en mi proyecto, realmente no necesitaba javadoc en absoluto. Solo algunos complementos necesarios tenían una dependencia de tiempo de compilación.
Entonces, la forma más simple de resolver mi problema fue:
fuente
A partir de maven-javadoc-plugin 3.0.0, debería haber estado utilizando una opción adicional para configurar una opción Javadoc adicional, por lo que si desea que Javadoc deshabilite doclint, debe agregar la siguiente propiedad.
También debe mencionar la versión de maven-javadoc-plugin como 3.0.0 o superior.
fuente
Entonces, ahórrate algunas horas que no hice y prueba esto si parece que no funciona:
La etiqueta se cambia para las versiones más nuevas.
fuente
-Xdoclint
sí mismo no es suficiente, pero se necesitan argumentos adicionales. Las versiones más nuevas de lamaven-javadoc-plugin
proporcionanadditionalJOptions
para eso, las más antiguas no. Una solución alternativa es: las<additionalJOption>"-Xdoclint:none" "--allow-script-in-comments"</additionalJOption>
citas son importantes, de lo contrario, el complemento las agrega y asume solo un argumento en lugar de dos, lo que generawrong args
errores.javadoc: error - Illegal package name: ""-Xdoclint:none" "--allow-script-in-comments""
las comillas externas se agregan mediante la declaración de registro y no están presentes en el shell. Supongo que el problema es que en Windowsjavadoc
se ejecuta mediantecmd.exe
, que analiza una cadena grande como línea de comando y divide la cadena segúnadditionalJOption
lo previsto. En Linux, los argumentos se pasan individualmente al proceso directamente yadditionalJOption
se pasan como un argumento, lo que lleva al error.Process Monitor
,cmd.exe
no se utiliza. Lo más probable es que Java simplemente construya una línea de comando grande y se la paseCreateProcess
, de modo que Windows la analice según lo previsto: dividir argumentos en espacios mientras se respetan las comillas.Agregado a continuación
En el trabajo de Jenkins:
Configuración> Entorno de compilación> Inyectar variables de entorno en el proceso de compilación> Contenido de propiedades
Resolvió mi problema de creación de código a través de Jenkins Maven :-)
fuente
mvn release:perform
la sintaxis debe sermvn release:perform -Darguments="-Dmaven.javadoc.skip=true"
.No estoy seguro de si esto va a ayudar, pero incluso recientemente me enfrenté al mismo problema con la versión oozie-4.2.0 . Después de leer las respuestas anteriores, acabo de agregar la opción maven a través de la línea de comandos y funcionó para mí. Entonces, solo compartiendo aquí.
Estoy usando Java 1.8.0_77 , no he probado con Java 1.7
bin / mkdistro.sh -DskipTests -Dmaven.javadoc.opts = '- Xdoclint: -html'
fuente
Para ignorar las etiquetas faltantes
@param
y@return
, es suficiente deshabilitar elmissing
grupo doclint . De esta forma, el javadoc aún se verificará para detectar problemas de nivel y sintaxis superiores:Tenga en cuenta que esto es para la versión del complemento 3.0 o posterior.
fuente
Llegué un poco tarde a la fiesta, pero también me vi obligado a buscar una solución, terminé aquí y luego lo encontré.
Esto es lo que funciona para mí:
Y luego comience su compilación de Maven, cualquier compilación de distribución de Linux, etc. Lo bueno es que no requiere la modificación de los archivos de configuración de Maven : no pude hacerlo ya que mi objetivo era reconstruir un montón de paquetes Centos rpm, así que tuve que ir muy profundo
fuente