Odkąd korzystam z Maven, byłem w stanie zbudować i zainstalować w moim lokalnym repozytorium projekty, które mają niekompletne tagi Javadoc (na przykład brakujący parametr).
Ponieważ jednak przeprowadziłem migrację do Javy 8 (1.8.0-ea-b90), Maven jest absolutnie surowy w kwestii brakujących znaczników dokumentacji i pokazuje mi wiele błędów Javadoc związanych z problemami Javadoc, gdy próbuję zbudować lub zainstalować projekt, w którym Javadoc nie jest "idealny". Niektóre projekty, które próbuję skompilować i zainstalować w moim lokalnym repozytorium, to projekty stron trzecich, nad którymi nie mam kontroli. Zatem obejście po prostu naprawienia wszystkich Javadoców we wszystkich tych projektach nie wydaje się wykonalne w moim scenariuszu.
Oto niewielka część danych wyjściowych, które widzę podczas wykonywania mvn clean package install
w moim projekcie:
[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] ^
Wtyczka Javadoc Maven jest skonfigurowana w następujący sposób w mojej 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>
Jak powiedziałem wcześniej, wszystko działa poprawnie, jeśli wrócę do Javy 7. Być może jest to błąd związany z działaniem Mavena w Javie 8? Jak mogę sprawić, by działało (tj. Móc zbudować Javadoc projektu i zainstalować jego kod w moim lokalnym repozytorium) z Javą 8? Testowałem zarówno z Maven 3.0.3, jak i 3.0.5 w OSX.
AKTUALIZACJA:
Jeśli zmienię konfigurację wtyczki Javadoc za pomocą <failOnError>false</failOnError>
(dzięki 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>
Następnie projekt jest instalowany w moim lokalnym repozytorium. Jednak JAR Javadoc nadal nie jest generowany.
Fragment danych wyjściowych, które widzę w konsoli w tej nowej konfiguracji, to:
[BŁĄD] MavenReportException: Błąd podczas tworzenia archiwum: Kod zakończenia: 1 - /Users/....java:18: ostrzeżenie: no @param ... Wiersz polecenia to: / Library / Java / Home / bin / javadoc @options @pakiety
Zapoznaj się z wygenerowanymi plikami Javadoc w katalogu „/ Users / sergioc / Documents / workspaces / heal / minitoolbox / target / apidocs”.
w org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeJavadocCommandLine (AbstractJavadocMojo.java:5043) w org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport (AbstractJavadocMo990) .javadoc.JavadocJar.execute (JavadocJar.java:181) w org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:101) w org.apache.maven.lifecycle.internal.MojoExecja : 209) w org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:153) w org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:145) w org.apache. maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:84) w org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:59) w org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild (LifecycleStarter.java:183) w org.apache.maven.lifecycle.internal.LifecycleStarter.execute (Lifecycle16arter.ja) w org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:320) w org.apache.maven.DefaultMaven.execute (DefaultMaven.java:156) w org.apache.maven.cli.MavenCli.execute (MavenCli.java : 537) w org.apache.maven.cli.MavenCli.doMain (MavenCli.java:196) w org.apache.maven.cli.MavenCli.main (MavenCli.java:141) w sun.reflect.NativeMethodAccessorImpl.invoke0 ( Metoda rodzima) w sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57) w sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) w java.lang.reflect.Method.wywołaj (Method.java:491) w org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:290) w org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:230) w org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:409) w org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:352)
Jakieś obejście dotyczące sposobu budowania źródeł, instalowania projektu i generowania pliku JAR Javadoc w jednym kroku podczas pracy z Javą 7?
Odpowiedzi:
Najlepszym rozwiązaniem byłoby naprawić błędy javadoc. Jeśli z jakiegoś powodu nie jest to możliwe (np. Automatycznie wygenerowany kod źródłowy), możesz wyłączyć tę kontrolę.
DocLint to nowa funkcja w Javie 8 , którą podsumowano jako:
Jest to domyślnie włączone i przed wygenerowaniem Javadocs przeprowadzi wiele kontroli. Musisz wyłączyć to dla Java 8, jak określono w tym wątku . Musisz dodać to do swojej konfiguracji maven:
Dla maven-javadoc-plugin 3.0.0+: Zamień
z
źródło
javadoc
nie zna tej opcji.<doclint>none</doclint>
. Zobacz maven.apache.org/plugins/maven-javadoc-plugin/…<additionalparam/>
został zastąpiony przez<additionalOptions/>
. Patrz problemy.apache.org/jira/browse/MJAVADOC-475Najłatwiejszym podejściem do pracy zarówno z java 8, jak i java 7 jest użycie profilu w kompilacji:
źródło
Oto najbardziej zwięzły sposób, w jaki jestem świadom ignorowania ostrzeżeń doclint niezależnie od używanej wersji Java. Nie ma potrzeby duplikowania konfiguracji wtyczek w wielu profilach z niewielkimi modyfikacjami.
Testowane na oracle / open jdk 6, 7, 8 i 11.
źródło
build
iprofiles
są bloki najwyższego poziomu w Mavenpom.xml
. maven.apache.org/pom.html#Build .Dodaj do sekcji właściwości globalnych w pliku pom:
Wspólne rozwiązanie podane tutaj w innych odpowiedziach (dodanie tej właściwości w sekcji wtyczek) z jakiegoś powodu nie działało. Tylko ustawiając go globalnie, mogłem pomyślnie zbudować słoik javadoc.
źródło
Najkrótsze rozwiązanie, które będzie działać z dowolną wersją Java:
Po prostu dodaj to do POM i możesz zacząć.
Jest to w zasadzie odpowiedź @ ankon plus odpowiedź @ zapp .
Dla użytkowników maven-javadoc-plugin 3.0.0:
Zastąpić
<additionalparam>-Xdoclint:none</additionalparam>
przez
<doclint>none</doclint>
źródło
<additionalJOption>-Xdoclint:none</additionalJOption>
lub<doclint>none</doclint>
własność do<properties>
<doclint>none</doclint>
(bez aktywacji opartej na wersji JDK), czy nadal będzie zawieść w JDK mniejszej niż 1.8, czy też wtyczka maven-javadoc automatycznie wykryje, czydoclint
opcja jest obsługiwana przez aktualną wersję Java?Nie sądzę, aby wyłączenie DocLint było dobrym rozwiązaniem, przynajmniej na dłuższą metę. Dobrze, że Javadoc stał się nieco bardziej rygorystyczny, więc właściwym sposobem rozwiązania problemu z kompilacją jest naprawienie podstawowego problemu . Tak, ostatecznie musisz naprawić te pliki kodu źródłowego.
Oto rzeczy, na które warto zwrócić uwagę:
{@link }
s. (to samo dotyczy podobnych tagów, takich jak@see
)@author
wartości Kiedyś było to akceptowane:@author John <[email protected]>
ale już nie tak z powodu nieuchwytnych nawiasów.Musisz po prostu naprawić pliki kodu źródłowego i kontynuować tworzenie Javadoc, dopóki nie będzie można go skompilować bez awarii. Uciążliwe tak, ale osobiście podoba mi się, kiedy podniosłem moje projekty do poziomu DocLint, ponieważ oznacza to, że mogę być bardziej pewny, że Javadoc, który produkuję, jest tym, co zamierzam.
Oczywiście istnieje problem, jeśli generujesz Javadoc na jakimś kodzie źródłowym, którego sam nie stworzyłeś, na przykład ponieważ pochodzi on z jakiegoś generatora kodu, np . Wsimport . Dziwne, że Oracle nie przygotowało własnych narzędzi do zgodności z JDK8 przed faktycznym wydaniem JDK8. Wygląda na to, że nie zostanie naprawiony, dopóki Java 9 . Tylko w tym konkretnym przypadku sugeruję wyłączenie DocLint zgodnie z dokumentacją w innym miejscu na tej stronie.
źródło
wsimport
aby stać się częścią Javadoc.Zastępowanie
maven-javadoc-plugin
tylko konfiguracji, nie rozwiązuje problemumvn site
(używane np. Na etapie wydania). Oto, co musiałem zrobić:źródło
maven-javadoc-plugin
pośrednictwem<reportPlugins>
sekcji niemaven-site-plugin
jest zalecana dla najnowszych wersji Maven 3.Możesz spróbować ustawić
failOnError
właściwość (patrz dokumentacja wtyczki ) nafalse
:Jak widać z dokumentów, wartością domyślną jest
true
.źródło
Ponieważ zależy to od wersji środowiska JRE używanego do uruchamiania polecenia maven, którego prawdopodobnie nie chcesz wyłączać
DocLint
domyślnie w pliku pom.xmlDlatego z wiersza poleceń możesz użyć przełącznika
-Dadditionalparam=-Xdoclint:none
.Przykład:
mvn clean install -Dadditionalparam=-Xdoclint:none
źródło
-Dadditionalparam=-Xdoclint:none
a wszystkie twoje kompilacje będą działać z Javą 8.mvn org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:jar -DadditionalJOption=-Xdoclint:none
- zadziałało dla mnieNazwa właściwości konfiguracji została zmieniona w najnowszej wersji wtyczki maven-javadoc, czyli 3.0.0.
Dlatego <additionalparam> nie będzie działać. Więc musimy to zmodyfikować jak poniżej.
źródło
doclint
dokumentację tutaj: maven.apache.org/plugins/maven-javadoc-plugin/…pom.xml
w katalogu src / build projektu. W moim przypadku wszystko, co musiałem zrobić, to poszukać,maven-javadoc-plugin
a następnie przejść do<configuration></configuration>
bloku już obecnego i dodać<doclint>none</doclint>
. Choć wszystko to jest raz znane, kontekst tutaj polega na tym, że próbuję naprawić inny błąd w OpenGrok i nigdy wcześniej nie korzystałem z Maven i nie chcę wracać do innego podprojektu, żeby się domyślić jak zastosować szybkie poprawki.Chciałbym dodać wgląd w inne odpowiedzi
W moim przypadku
Nie działało
Zacznijmy od tego, że w moim projekcie tak naprawdę wcale nie potrzebowałem javadoc. Tylko niektóre niezbędne wtyczki zależały od czasu kompilacji.
Najprostszym sposobem rozwiązania mojego problemu było:
źródło
Począwszy od maven-javadoc-plugin 3.0.0, powinieneś był używać dodatkowej opcji JOption, aby ustawić dodatkową opcję Javadoc, więc jeśli chcesz, aby Javadoc wyłączał doclint, powinieneś dodać następującą właściwość.
Należy również wspomnieć o wersji wtyczki maven-javadoc jako 3.0.0 lub nowszej.
źródło
Więc zaoszczędź sobie kilka godzin, których nie zrobiłem i wypróbuj to, jeśli wydaje się, że nie działa:
Tag został zmieniony dla nowszych wersji.
źródło
-Xdoclint
sama nie wystarczy, ale potrzebne są dodatkowe argumenty. Nowsze wersjemaven-javadoc-plugin
zapewniająadditionalJOptions
to, starsze nie. Obejście problemu:<additionalJOption>"-Xdoclint:none" "--allow-script-in-comments"</additionalJOption>
Cytaty są ważne, w przeciwnym razie wtyczka doda je i przyjmie tylko jeden argument zamiast dwóch, co spowodujewrong args
błędy.javadoc: error - Illegal package name: ""-Xdoclint:none" "--allow-script-in-comments""
cytaty zewnętrzne są dodawane przez instrukcję logowania i nie są obecne w powłoce. Myślę, że problem polega na tym, że w systemie Windowsjavadoc
jest wykonywany przezcmd.exe
, który analizuje jeden duży ciąg jako linię poleceń i dzieliadditionalJOption
zgodnie z przeznaczeniem. W systemie Linux argumenty są przekazywane bezpośrednio do procesu iadditionalJOption
są przekazywane jako jeden argument, co prowadzi do błędu.Process Monitor
,cmd.exe
nie jest używany. Najprawdopodobniej Java po prostu buduje jeden duży wiersz poleceń i przekazuje go do tegoCreateProcess
, aby został przeanalizowany przez system Windows zgodnie z przeznaczeniem: Dzielenie argumentów spacjami podczas honorowania cudzysłowów.Dodano poniżej
Do pracy Jenkinsa:
Konfiguracja> Środowisko kompilacji> Wprowadzaj zmienne środowiskowe do procesu budowania> Zawartość Właściwości
Rozwiązałem mój problem z budowaniem kodu przez Jenkins Maven :-)
źródło
mvn release:perform
składni musi byćmvn release:perform -Darguments="-Dmaven.javadoc.skip=true"
.Nie jestem pewien, czy to pomoże, ale nawet ostatnio miałem dokładnie taki sam problem z wersją oozie-4.2.0 . Po przeczytaniu powyższych odpowiedzi właśnie dodałem opcję maven za pomocą wiersza poleceń i zadziałało to dla mnie. Udostępniam tutaj.
Używam java 1.8.0_77 , nie próbowałem z java 1.7
bin / mkdistro.sh -DskipTests -Dmaven.javadoc.opts = '- Xdoclint: -html'
źródło
Aby zignorować brakujące
@param
i@return
znaczniki, wystarczy wyłączyćmissing
grupę dokumentów . W ten sposób javadoc będzie nadal sprawdzany pod kątem problemów z wyższym poziomem i składnią:Pamiętaj, że dotyczy to wtyczki w wersji 3.0 lub nowszej.
źródło
Jestem trochę spóźniony na przyjęcie, ale musiałem też szukać obejścia, znalazłem się tutaj, a potem go znalazłem.
Oto, co działa dla mnie: -
A potem rozpocznij kompilację Maven, dowolną kompilację dystrybucji Linuksa itp. Fajną rzeczą jest to, że nie wymaga modyfikacji plików konfiguracyjnych Maven - nie mogłem tego zrobić, ponieważ moim celem było przebudowanie wielu pakietów rpm Centos , więc musiałem idź naprawdę głęboko.
źródło