Maven ne fonctionne pas dans Java 8 lorsque les balises Javadoc sont incomplètes


312

Depuis que j'utilise Maven, j'ai pu créer et installer dans mes projets de référentiel local des balises Javadoc incomplètes (par exemple, un paramètre manquant).

Cependant, depuis que j'ai migré vers Java 8 (1.8.0-ea-b90) Maven est absolument strict sur les balises de documentation manquantes et me montre beaucoup d'erreurs Javadoc liées aux problèmes Javadoc lorsque j'essaie de construire ou d'installer un projet où le Javadoc n'est pas "parfait". Certains des projets que j'essaye de compiler et d'installer dans mon référentiel local sont des projets tiers dont je n'ai pas le contrôle. Ainsi, la solution de contournement consistant à simplement réparer tous les Javadocs dans tous ces projets ne semble pas réalisable dans mon scénario.

Ceci est une petite partie de la sortie que je vois lorsque j'exécute mvn clean package installdans mon projet:

[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] ^

Le plugin Javadoc Maven est configuré comme ceci dans mon 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>

Comme je l'ai déjà dit, tout fonctionne bien si je reviens à Java 7. Peut-être est-ce un bug lié à Maven fonctionnant en Java 8? Comment pourrais-je le faire fonctionner (c'est-à-dire pouvoir construire le Javadoc du projet et installer son code dans mon dépôt local) avec Java 8? J'ai testé avec Maven 3.0.3 et 3.0.5 sous OSX.

METTRE À JOUR:

Si je change ma configuration de plugin Javadoc avec <failOnError>false</failOnError>(merci 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>

Ensuite, le projet est installé dans mon référentiel local. Cependant, le JAR Javadoc n'est toujours pas généré.

Un fragment de la sortie que je vois dans la console avec cette nouvelle configuration est:

[ERREUR] MavenReportException: erreur lors de la création de l'archive: code de sortie: 1 - /Users/....java:18: avertissement: pas de @param ... La ligne de commande était: / Library / Java / Home / bin / javadoc @options @paquets

Reportez-vous aux fichiers Javadoc générés dans le répertoire '/ Users / sergioc / Documents / workspaces / heal / minitoolbox / target / apidocs'.

à org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeJavadocCommandLine (AbstractJavadocMojo.java:5043) à org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport (AbstractJavadocMojo.executeReport (RésuméJavadocMojo.executeReport) .javadoc.JavadocJar.execute (JavadocJar.java:181) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor : 209) sur org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:153) sur org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:145) sur org.apache. maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:84) sur org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:59) à org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild (LifecycleStarter.java:183) à org.apache.maven.lifecycle.internal.LifecycleStarter.execute (Ljecycle). à org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:320) à org.apache.maven.DefaultMaven.execute (DefaultMaven.java:156) à org.apache.maven.cli.MavenCli.execute (MavenCli.java : 537) à org.apache.maven.cli.MavenCli.doMain (MavenCli.java:196) à org.apache.maven.cli.MavenCli.main (MavenCli.java:141) à sun.reflect.NativeMethodAccessorImpl.invoke0 ( Native Method) sur sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57) sur sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) sur java.lang.reflect.Method.invoquer (Method.java:491) sur org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:290) sur org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:230) à org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:409) à org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:352)

Une solution de contournement sur la façon de générer les sources, d'installer le projet et de générer le JAR Javadoc en une seule étape alors qu'il fonctionnait avec Java 7?


Salut @ 75inchpianist, j'ai mis à jour la question, en fait ce sont des erreurs (bien qu'étonnamment, la dernière ligne de l'erreur fait référence à un avertissement, comme vous pouvez le voir dans la sortie générée). Le projet n'est pas installé dans mon référentiel local, il n'est donc pas considéré comme un simple avertissement :(
Sergio

Pour GoogleJuice: J'ai eu l'erreur "erreur: mauvaise utilisation de '>'" car j'avais une grosse flèche dans le commentaire JavaDoc
Drew Stephens

1
Peut-être que cela sera utile pour quelqu'un: vous pouvez facilement trouver toutes ces balises incomplètes dans IntelliJ en exécutant l'inspection Ctrl + Alt + Maj + i "La déclaration a des problèmes JavaDoc"
Sergey Ponomarev

1
Ce n'est pas maven, c'est le programme javadoc qui est devenu beaucoup plus strict en Java 8.
Thorbjørn Ravn Andersen

Réponses:


388

La meilleure solution serait de corriger les erreurs javadoc. Si pour une raison quelconque, cela n'est pas possible (par exemple: code source généré automatiquement), vous pouvez désactiver cette vérification.

DocLint est une nouvelle fonctionnalité de Java 8 , qui se résume comme suit:

Fournir un moyen de détecter les erreurs dans les commentaires Javadoc au début du cycle de développement et d'une manière qui est facilement liée au code source.

Ceci est activé par défaut et exécutera de nombreuses vérifications avant de générer des Javadocs. Vous devez désactiver cela pour Java 8 comme spécifié dans ce fil . Vous devrez l'ajouter à votre configuration maven:

<profiles>
  <profile>
    <id>java8-doclint-disabled</id>
    <activation>
      <jdk>[1.8,)</jdk>
    </activation>
    <properties>
      <javadoc.opts>-Xdoclint:none</javadoc.opts>
    </properties>
  </profile>
</profiles>
<build>
  <plugins>
    <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>
                <configuration>
                    <additionalparam>${javadoc.opts}</additionalparam>
                </configuration>
            </execution>
        </executions>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.3</version>
        <configuration>
          <reportPlugins>
            <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-javadoc-plugin</artifactId>
              <configuration>
                <additionalparam>${javadoc.opts}</additionalparam>
              </configuration>
            </plugin>
          </reportPlugins>
        </configuration>
      </plugin>
   </plugins>
</build>

Pour maven-javadoc-plugin 3.0.0+: Remplacer

<additionalparam>-Xdoclint:none</additionalparam>

avec

<doclint>none</doclint>

18
Existe-t-il un moyen de faire fonctionner cela avec JDK 8 ainsi qu'avec JDK 7? Il échoue sur JDK 7 car javadocil ne connaît pas cette option.
Feuermurmel

8
Bien que cela réponde à la question posée ici, je voudrais conseiller aux futurs visiteurs de vérifier d'abord la réponse de Peter: stackoverflow.com/a/34809831/1180785 (la plupart des gens qui rencontrent ce problème n'auront qu'une poignée d'endroits à corriger, il est donc préférable pour les réparer que de désactiver la vérification!)
Dave

8
Pour le plugin maven-javadoc, utilisez <doclint>none</doclint>. Voir maven.apache.org/plugins/maven-javadoc-plugin/…
coolersport

11
Également depuis maven-javadoc-plugin 3.0.0, <additionalparam/>est remplacé par <additionalOptions/>. Voir issues.apache.org/jira/browse/MJAVADOC-475
fdelsert

1
C'est correct. Je voudrais signaler que lors de la migration de maven 2 vers maven 3, n'oubliez pas que cette balise de plugin ne doit pas être incluse dans la balise de reporting mais directement dans pluginManagement (pom.xml)
dimeros

97

L'approche la plus simple pour que les choses fonctionnent avec java 8 et java 7 consiste à utiliser un profil dans la build:

<profiles>
  <profile>
    <id>doclint-java8-disable</id>
    <activation>
      <jdk>[1.8,)</jdk>
    </activation>

    <build>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-javadoc-plugin</artifactId>
          <configuration>
            <additionalparam>-Xdoclint:none</additionalparam>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

1
La meilleure solution serait probablement un hybride entre votre solution et celle fournie par Zapp. Si vous le laissez de cette façon, la commande mvn site: site plantera toujours. Vous devez créer un profil activé par le 1.8 jdk qui définit une propriété globale.
Max Nad

64

Voici le moyen le plus concis que je connaisse pour ignorer les avertissements doclint quelle que soit la version java utilisée. Il n'est pas nécessaire de dupliquer la configuration du plugin dans plusieurs profils avec de légères modifications.

<profiles>
  <profile>
    <id>doclint-java8-disable</id>
    <activation>
      <jdk>[1.8,)</jdk>
    </activation>
    <properties>
      <javadoc.opts>-Xdoclint:none</javadoc.opts>
    </properties>
  </profile>
</profiles>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <version>2.9.1</version>
      <executions>
        <execution>
          <id>attach-javadocs</id> <!-- The actual id should be apparent from maven output -->
          <configuration>
            <additionalparam>${javadoc.opts}</additionalparam>
          </configuration>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>

Testé sur oracle / open jdk 6, 7, 8 et 11.


1
Et où cela devrait-il être mis spécifiquement?
clearlight

1
@clearlight, les deux buildet profilessont des blocs de niveau supérieur dans maven pom.xml. maven.apache.org/pom.html#Build .
Oliver Gondža

Merci. J'ai finalement découvert cela, mais c'est bien d'avoir cela associé à cette réponse.
clearlight

38

Ajoutez dans la section des propriétés globales du fichier pom:

<project>
    ...
    <properties>
        <additionalparam>-Xdoclint:none</additionalparam>
    </properties>

La solution commune fournie ici dans les autres réponses (en ajoutant cette propriété dans la section plugins) n'a pas fonctionné pour une raison quelconque. Ce n'est qu'en le définissant globalement que j'ai pu construire le pot javadoc avec succès.


1
c'est la seule solution qui a fonctionné pour moi. J'ai également lu la réponse ici: blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
acvcu

37

La solution la plus courte qui fonctionnera avec n'importe quelle version Java:

<profiles>
    <profile>
        <id>disable-java8-doclint</id>
        <activation>
            <jdk>[1.8,)</jdk>
        </activation>
        <properties>
            <additionalparam>-Xdoclint:none</additionalparam>
        </properties>
    </profile>
</profiles>

Ajoutez simplement cela à votre POM et vous êtes prêt à partir.

Ceci est essentiellement @ la réponse de ankon , plus @ la réponse de Zapp .


Pour les utilisateurs de maven-javadoc-plugin 3.0.0:

Remplacer

<additionalparam>-Xdoclint:none</additionalparam>

par

<doclint>none</doclint>


C'est la meilleure solution pour moi. Cela fonctionne pour les bots java 7 et java 8. Mais la façon dont cela fonctionne est une sorte de magie:. Comment ce paramètre "additionalParam" s'ajoute au plugin javadoc (et pas aux autres)
pdem

1
@pdem Le paramètre supplémentaire est ajouté à Maven, pas au plugin Javadoc. Cette solution fonctionne que vous utilisiez explicitement le plugin ou non.
Fred Porciúncula

2
Depuis maven-javadoc-plugin 3.0.0, vous devez ajouter <additionalJOption>-Xdoclint:none</additionalJOption>une <doclint>none</doclint>propriété à votre<properties>
Sergi

Oui, l'ajout d'un profil et d'un paramètre liés à JDK 8 <doclint> aucun </doclint> résout le problème. Il génère un fichier javadoc identique à celui qu'il générait dans JDK 7. Merci.
Saurabhcdt

1
Pouvez-vous préciser: avec maven-javadoc-plugin 3.0.0 et supérieur, si je spécifie simplement <doclint>none</doclint>(sans activation basée sur la version JDK), est-ce qu'il échouera toujours sur JDK inférieur à 1,8, ou maven-javadoc-plugin détectera-t-il automatiquement si l' doclintoption est prise en charge par la version actuelle de Java?
Garret Wilson

31

Je ne pense pas que désactiver DocLint soit une bonne solution, du moins pas à long terme. Il est bon que Javadoc soit devenu un peu plus strict, donc la bonne façon de résoudre le problème de construction est de résoudre le problème sous-jacent . Oui, vous devrez finalement corriger ces fichiers de code source.

Voici les choses à surveiller avec lesquelles vous pourriez vous en sortir:

  • HTML mal formé (par exemple, une balise de fin manquante, des crochets non échappés, etc.)
  • Invalide {@link }s. (il en va de même pour des balises similaires telles que @see)
  • @authorValeurs invalides . Auparavant, cela était accepté: @author John <john.doe@mine.com>mais ce n'est plus le cas à cause des crochets non échappés.
  • Les tableaux HTML dans Javadoc nécessitent désormais un résumé ou une légende. Voir cette question pour une explication.

Vous devrez simplement corriger vos fichiers de code source et continuer à construire votre Javadoc jusqu'à ce qu'il puisse être construit sans échec. Lourd oui, mais personnellement j'aime quand j'ai porté mes projets au niveau DocLint parce que cela signifie que je peux être plus confiant que le Javadoc que je produis est en fait ce que j'ai l'intention.

Il y a bien sûr le problème si vous générez Javadoc sur du code source que vous n'avez pas produit vous-même, par exemple parce qu'il provient d'un générateur de code, par exemple wsimport . Il est étrange qu'Oracle n'ait pas préparé ses propres outils pour la conformité JDK8 avant de publier JDK8. Il semble qu'il ne sera pas corrigé avant Java 9 . Seulement dans ce cas particulier, je suggère de désactiver DocLint comme indiqué ailleurs sur cette page.


1
Entièrement d'accord ici, cela dit, pour le code généré, vous pouvez simplement dire au plugin de ne pas traiter le code dans un package donné en ajoutant une section excludePackageNames dans la section de configuration du plugin javadoc. voir maven.apache.org/plugins/maven-javadoc-plugin/examples/…
Newtopian

@Newtopian. Bon point. Cependant, dans mon cas, j'avais réellement besoin du code généré par wsimportpour faire partie de Javadoc.
peterh

C'est tellement plus facile à dire qu'à faire car beaucoup d'entre nous rencontrant ces problèmes essaient de créer un code opensource inconnu qui a une dépendance Maven quelque part et nous n'avons aucune idée de la façon dont tout cela fonctionne, donc nous n'avons pas de moyen facile de traiter les causes sous-jacentes. Il y a trop de myopie dans le contexte. Les gens ont besoin de généraliser davantage la portée des réponses et de fournir plus de détails sur la façon d'apporter les correctifs.
clearlight

30

Ignorer la maven-javadoc-pluginconfiguration uniquement, ne résout pas le problème avec mvn site(utilisé par exemple pendant la phase de publication). Voici ce que je devais faire:

<profile>
  <id>doclint-java8-disable</id>
  <activation>
    <jdk>[1.8,)</jdk>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <configuration>
          <additionalparam>-Xdoclint:none</additionalparam>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.3</version>
        <configuration>
          <reportPlugins>
            <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-javadoc-plugin</artifactId>
              <configuration>
                <additionalparam>-Xdoclint:none</additionalparam>
              </configuration>
            </plugin>
          </reportPlugins>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

3
Ceci est un point important car l'absence de ce paramètre dans l'activation du plug-in de site entraînera la libération: l'exécution échouera pendant la libération: la préparation a bien fonctionné. Cela peut être un problème très ennuyeux à trouver et à corriger.
Peter N. Steinmetz

Notez que la configuration de maven-javadoc-pluginvia via la <reportPlugins>section du maven-site-pluginn'est pas recommandée pour les versions récentes de Maven 3.
Martin Höller

@ MartinHöller Alors, comment résoudre les erreurs à la sortie: effectuer correctement l'étape liée à mavene-javadoc-plugin: 3.0.1?
Vitalii Diravka

@VitaliiDiravka Dépend des erreurs ... Veuillez poser une question distincte à ce sujet.
Martin Höller

22

Vous pouvez essayer de définir la failOnErrorpropriété (voir la documentation du plugin ) sur false:

<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>
            <configuration>
              <failOnError>false</failOnError>
            </configuration>
        </execution>
    </executions>
</plugin>

Comme vous pouvez le voir dans les documents, la valeur par défaut est true.


Merci pour l'idée @Martin. Avec cette propriété au moins, je peux à nouveau construire et installer le projet, mais il me manque toujours le java doc jar (j'en ai besoin pour le déployer sur Maven central). J'ai mis à jour ma question avec les détails de l'expérience.
Sergio

C'était la réponse la plus suffisante pour moi. Je voulais juste tester la construction pendant le développement en cours lorsque les javadocs étaient encore incomplets.
ZachSand

17

Comme cela dépend de la version de votre JRE qui est utilisée pour exécuter la commande maven, vous ne voulez probablement pas désactiver DocLintpar défaut dans votre pom.xml

Par conséquent, à partir de la ligne de commande, vous pouvez utiliser le commutateur -Dadditionalparam=-Xdoclint:none.

Exemple: mvn clean install -Dadditionalparam=-Xdoclint:none


3
Ceci est particulièrement utile car vous pouvez également l'utiliser Jenkins. Réglez «Global MAVEN_OPTS» (sous «Configurer le système») sur -Dadditionalparam=-Xdoclint:noneet toutes vos versions fonctionneront avec Java 8.
Wilfred Hughes

mvn org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:jar -DadditionalJOption=-Xdoclint:none- cela a fonctionné pour moi
Roman Khomyshynets

10

Le nom de la propriété de configuration a été modifié dans la dernière version de maven-javadoc-plugin qui est 3.0.0.

Par conséquent, le <additionalparam> ne fonctionnera pas. Nous devons donc le modifier comme ci-dessous.

   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <version>3.0.0</version>
      <configuration>
         <doclint>none</doclint>
      </configuration>
  </plugin>

Voir la doclintdocumentation ici: maven.apache.org/plugins/maven-javadoc-plugin/…
Peter W

Résolu pour moi la construction d'OpenGrok à partir de la source github en février 19. Devrait mentionner que votre correctif va dans pom.xmlle répertoire src / build du projet. Dans mon cas, tout ce que j'avais à faire était de rechercher maven-javadoc-pluginpuis d'aller dans le <configuration></configuration>bloc déjà présent et d'ajouter <doclint>none</doclint>. Aussi simple que tout cela soit une fois que l'on sait, le contexte ici est que j'essaie de corriger un bogue différent dans OpenGrok et que je n'ai jamais utilisé Maven auparavant et que je ne veux pas avoir à rentrer dans un autre sous-projet juste pour avoir à comprendre comment appliquer des correctifs rapides.
clearlight

4

Je voudrais ajouter un aperçu d'autres réponses

Dans mon cas

-Xdoclint: aucun

Ça n'a pas marché.

Commençons par ça, dans mon projet, je n'avais pas vraiment besoin de javadoc. Seuls certains plugins nécessaires avaient une dépendance de temps de construction.

Donc, la façon la plus simple de résoudre mon problème était:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

4

Depuis maven-javadoc-plugin 3.0.0, vous auriez dû utiliser additionalJOption pour définir une option Javadoc supplémentaire, donc si vous souhaitez que Javadoc désactive doclint, vous devez ajouter la propriété suivante.

<properties>
    ...
    <additionalJOption>-Xdoclint:none</additionalJOption>
    ...
<properties>

Vous devez également mentionner la version de maven-javadoc-plugin comme 3.0.0 ou supérieure.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>3.0.0</version>    
</plugin>

3

Alors, économisez-vous quelques heures que je n'ai pas faites et essayez ceci si cela ne semble pas fonctionner:

 <additionalJOption>-Xdoclint:none</additionalJOption>

La balise est modifiée pour les versions plus récentes.



Parfois, cela -Xdoclintne suffit pas, mais des arguments supplémentaires sont nécessaires. Les nouvelles versions de la maven-javadoc-pluginprévoient additionalJOptionscela, les anciennes non. Une solution de contournement est la suivante: les <additionalJOption>"-Xdoclint:none" "--allow-script-in-comments"</additionalJOption>citations sont importantes, sinon le plugin les ajoute et suppose un seul argument au lieu de deux, ce qui entraîne des wrong argserreurs.
Thorsten Schöning

Le premier fonctionne uniquement sur Windows, sur Linux à la place: javadoc: error - Illegal package name: ""-Xdoclint:none" "--allow-script-in-comments""les guillemets externes sont ajoutés par l'instruction de journalisation et ne sont pas présents sur le shell. Je suppose que le problème est que sur Windows javadocest exécuté par cmd.exe, qui analyse une grande chaîne en ligne de commande et divise le additionalJOptioncomme prévu. Sous Linux, les arguments sont transmis individuellement au processus directement et additionalJOptionsont transmis comme un argument, ce qui entraîne l'erreur.
Thorsten Schöning

Selon Process Monitor, cmd.exen'est pas utilisé. Java construit très probablement simplement une grande ligne de commande et la transmet à CreateProcess, afin qu'elle soit analysée par Windows comme prévu: Fractionner les arguments dans les espaces tout en respectant les guillemets.
Thorsten Schöning

3

Ajouté ci-dessous

JAVA_TOOL_OPTIONS=-DadditionalJOption=-Xdoclint:none

Dans le travail Jenkins:

Configuration> Environnement de génération> Injection de variables d'environnement au processus de génération> Contenu des propriétés

Résolu mon problème de construction de code via Jenkins Maven :-)


Cela fonctionne pour maven-javadoc-plugin 2.4 mais à partir de la version 2.5 (et jusqu'à 3.0.0), cela provoque une erreur: "Code de sortie: 1 - javadoc: erreur - drapeau invalide: -Xdoclint: aucun". La solution est donc fragile.
Akom

1
Lorsque vous utilisez cela avec mvn release:performla syntaxe doit être mvn release:perform -Darguments="-Dmaven.javadoc.skip=true".
PatS

2

Je ne sais pas si cela va aider, mais même j'ai rencontré le même problème très récemment avec la version oozie-4.2.0 . Après avoir lu les réponses ci-dessus, je viens d'ajouter l'option maven via la ligne de commande et cela a fonctionné pour moi. Donc, juste partager ici.

J'utilise java 1.8.0_77 , je n'ai pas essayé avec java 1.7

bin / mkdistro.sh -DskipTests -Dmaven.javadoc.opts = '- Xdoclint: -html'


1

Pour ignorer les balises manquantes @paramet @return, il suffit de désactiver le missing groupe doclint . De cette façon, le javadoc sera toujours vérifié pour les problèmes de niveau supérieur et de syntaxe:

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>3.0.0</version>
        <configuration>
            <doclint>all,-missing</doclint>
        </configuration>
    </plugin>

Notez que c'est pour le plugin version 3.0 ou plus récent.


0

Je suis un peu en retard à la fête, mais j'ai également été obligé de chercher une solution de contournement, je me suis retrouvé ici, puis je l'ai trouvé.

Voici ce qui fonctionne pour moi: -

export JAVA_TOOL_OPTIONS=-DadditionalJOption=-Xdoclint:none

Et puis démarrez votre build Maven, n'importe quelle build de distribution Linux, etc. Heureusement qu'il ne nécessite pas de modification des fichiers de configuration Maven - je ne pouvais pas le faire car mon objectif était de reconstruire un tas de paquets rpm Centos , donc je devais aller vraiment en profondeur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.