I am migrating the MWS Feeds API project from Ant to Maven. See MWS Feeds Maven port.
I get all the time the same error which makes no sense for me when executing mvn javadoc:fix.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:fix (default-cli)
on project amazon-mws-feeds-maven: Execution default-cli of goal
org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:fix failed: A
required class was missing while executing
org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:fix:
com/amazonaws/mws/feeds/model/ReportInfo (wrong name:
com/amazonaws/mws/feeds/model//ReportInfo)
My Maven version:
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Users/dmytro/.sdkman/candidates/java/11.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"
How can I debug and fix it? I searched on StackOverflow, searched via natural search, and run mvn -X clean install but so far no results.
Asumption
The error message implies that a type resolution failed (class is missing) and this seems to happen because the plugin tries to resolve a slightly invalid path (notice the double slashes in "wrong name: com/amazonaws/mws/feeds/model//ReportInfo").
Identifying the problem
I started with mvn -X javadoc:fix in order to enable debuging. The output was very helpful:
[DEBUG] Analyzing com.amazonaws.mws.feeds.model.GetFeedSubmissionListByNextTokenResult
[INFO] Saving changes to com.amazonaws.mws.feeds.model.GetFeedSubmissionListByNextTokenResult
[DEBUG] Analyzing com.amazonaws.mws.feeds.model.UpdateReportAcknowledgementsResult
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
The last class successfully processed was GetFeedSubmissionListByNextTokenResult (the processing order is not always the same but that's irrelevant) but UpdateReportAcknowledgementsResult failed. Now we can focus on this class.
Further investigation on the stack trace revealed that the exception occurred while the plugin was fixing (replacing) link tags (the familiar {#link ClassName} javadoc tag):
at com.thoughtworks.qdox.type.TypeResolver.resolveTypeInternal (TypeResolver.java:187)
at com.thoughtworks.qdox.type.TypeResolver.resolveType (TypeResolver.java:119)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.replaceLinkTags (AbstractFixJavadocMojo.java:1858)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.updateJavadocComment (AbstractFixJavadocMojo.java:1808)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.updateJavadocComment (AbstractFixJavadocMojo.java:1756)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.updateEntityComment (AbstractFixJavadocMojo.java:1632)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.fixMethodComment (AbstractFixJavadocMojo.java:1486)
at org.apache.maven.plugins.javadoc.AbstractFixJavadocMojo.processFix (AbstractFixJavadocMojo.java:1100)
Now we know what to search for in that class.
Root cause
The real problem was immediately obvious, for example at UpdateReportAcknowledgementsResult:147
// #param values a {#link .ReportInfo} object.
That dot before the class name is not correctly handled in QDOX's TypeResolver. Once I removed all {#link .X} occurrences, the plugin was executed successfully.
My guess is that these dots were put there by mistake during a massive find-and-replace operation. A friend of mine did something similar once...
#DmytroChasovskyi This is not an answer, but a set of things you can try in order to help to resolve the problem.
Probably you have already try it, but if it is not the case, invoke the maven goal, isolated, and with the -e flag.
mvn -e javadoc:fix
Maybe it will give you further information about what is going on.
Try to reduce the number of elements that should be fixed. As you can see in the docs, you have flags that allows you to choose whether classes, fields or methods comments should be fixed. Play with it, it could be of some help.
You can also change the jdk compliance level: you are compiling for Java 1.6. Just for advance in the resolution of the problem, if possible, use another java target version.
One last thing you can try is use another JVM to execute the build and see it the problem still is there.
Finally, the fix goal of the Maven Javavoc Plugin is highly dependant on QDOX; it could be maybe some work, but maybe you can implement some test directly with that library and try to process your code to see if the problem persists.
Related
I have been trying to get more into the methodology of continuous integration as of recent, and have chosen Travis CI for the job. However, on one of my projects that uses Java and Kotlin my local builds pass, but fail on Travis.
I've been unable to make sense of the error messages that I am getting as to why my build is failing. kotlin-maven-plugin seems to be the origin of the errors. The problematic command as seen in the build logs is mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V.
I have run this command locally with no errors and a successful build.
Here's a relevant snippet of the stack trace from the CI Build Job:
[INFO] --- kotlin-maven-plugin:1.4.32:compile (compile) # BytesToJava ---
[ERROR] java.lang.ExceptionInInitializerError
at com.intellij.pom.java.LanguageLevel.<clinit>(LanguageLevel.java:25)
at com.intellij.core.CoreLanguageLevelProjectExtension.<init>(CoreLanguageLevelProjectExtension.java:26)
at com.intellij.core.JavaCoreProjectEnvironment.<init>(JavaCoreProjectEnvironment.java:42)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreProjectEnvironment.<init>(KotlinCoreProjectEnvironment.kt:26)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.<init>(KotlinCoreEnvironment.kt:121)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:425)
Would appreciate some resources or even a relevant issue thread. Thanks in advance :)
Travis Build Logs
The problem was being caused by an issue with illegal reflective operations and the Kotlin Maven Plugin with any project over Java 9 (my project uses Java 15). As described by this thread on YouTrack, a workaround is to:
A workaround is to run mvn with the following environment variable: MAVEN_OPTS=--illegal-access=permit
Adding a global environment variable with the same value to my .travis.yml fixed the issue.
Using Java 11.0.9 (GraalVM CE 20.3.0) wth a Micronaut 2.2.1 app making use of Firebase admin 7.1.0, when I package my app as a native image according to the Micronaut documentation, I get the following error:
$ ./gradlew nativeImage
> Task :nativeImage
[application:15026] classlist: 4,054.46 ms, 1.19 GB
[application:15026] (cap): 504.32 ms, 1.19 GB
[application:15026] setup: 1,827.02 ms, 1.19 GB
To see how the classes got initialized, use --trace-class-initialization=org.conscrypt.Conscrypt,org.conscrypt.OpenSSLProvider
[application:15026] analysis: 29,787.52 ms, 3.90 GB
Error: Classes that should be initialized at run time got initialized during image building:
org.conscrypt.Conscrypt was unintentionally initialized at build time. To see why org.conscrypt.Conscrypt got initialized use --trace-class-initialization=org.conscrypt.Conscrypt
org.conscrypt.OpenSSLProvider was unintentionally initialized at build time. To see why org.conscrypt.OpenSSLProvider got initialized use --trace-class-initialization=org.conscrypt.OpenSSLProvider
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1
> Task :nativeImage FAILED
FAILURE: Build failed with an exception.
The issue is caused by classes from the package org.conscrypt. The related dependency is from
com.google.cloud:google-cloud-firestore:1.35.0 that fetches org.conscrypt:conscrypt-openjdk-uber:2.2.1.
I am really new with GraalVM and far from understanding the cause of such an issue. However, I noticed it should be possible to pass to native-image some parameters, such as --initialize-at-build-time.
My question is how to fix this issue? is there a configuration file to create and that Micronaut reads from options to forward to the native-image executable?
The issue is caused by com.google.cloud:google-cloud-firestore:1.35.0 and how it uses its dependencies. This dependency does not support native images out of the box.
There is an ongoing effort to add support for GraalVM in this official repository:
https://github.com/GoogleCloudPlatform/google-cloud-graalvm-support
Adding this library as a compile dependency fixes the issue.
Regarding native-image configuration with Micronaut, you can pass options via a configuration file. Let's say your groupId is com.acme and your artifactId is acme-module1, then you need to create in your project the file src/main/resources/META-INF/native-image/com/acme/acme-module1/native-image.properties with your content:
Args = ...
We are trying to setup corda and run the cordapp-example on our macbook using Intellij. I am getting an error which says that the NodeDriver.main() failed but unable to debug as to what the failure is.
This is only explanation of the error:
Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_251.jdk/Contents/Home/bin/java'' finished with non-zero exit value 132
I am following the setup instructions on https://docs.corda.net/docs/corda-os/4.4/getting-set-up.html and the run instructions from https://docs.corda.net/docs/corda-os/4.4/tutorial-cordapp.html.
Gradle version: 5.4.1
JDK: 1.8.251
The error mostly comes because of the conflicting version of Java. I guess it is because a higher version of Java may be installed on your machine which the system might be defaulting to.
I suggest you should try to check and remove any conflicting Java versions or set Java 1.8 as default.
Unburden
First of all, I would like to unburden: Android Studio completely sucks and it is by far the worst big IDE I've used all my life long! I got stuck on errors just for opening that thing! And when I have hardly fixed one, seventeen new ones come rightly from the hell to my screen! I am (trying) to use that piece of [you know] for 4 days now, and till now I was not able to code one single line of code! What does an IDE is supposed to be useful for again?
-- Edit1: I just installed the full 1.4.1 version right now and first thing it showed me was: WizardException: Ignoring unknown package filter 'source-25' and others errors.
-- Edit2: I did a new FRESH Mint 18 install in a completely clean partition, installed only Java 7 (Oracle) and tried to run the AS-1.5.1 but... the same error on install and a subtle different log of error messages (please, see the log here) when gradleing.
The problem
Ok, the last problem (1.5.1) is that now I am trying to make gradle to build the "project" (it is just an empty activity created by the wizard, default code untouched) and I get this error:
~/AndroidStudioProjects/MyApplication $ gradle clean build --stacktrace
Incremental java compilation is an incubating feature.
:clean UP-TO-DATE
:app:clean
//...[other succesfull msgs here]...
:app:mergeDebugResourcesAAPT err(Facade for 16120822): /home/sidney/Android/Sdk/build-tools/25.0.0/aapt: 3: /home/sidney/Android/Sdk/build-tools/25.0.0/aapt: Syntax error: Unterminated quoted string
AAPT err(Facade for 22545775): /home/sidney/Android/Sdk/build-tools/25.0.0/aapt: 3: /home/sidney/Android/Sdk/build-tools/25.0.0/aapt: Syntax error: Unterminated quoted string
//...[other repeated errors here]...
Exception in thread "png-cruncher_8" java.lang.RuntimeException: Timed out while waiting for slave aapt process, make sure the aapt execute at /home/sidney/Android/Sdk/build-tools/25.0.0/aapt can run successfully (some anti-virus may block it) or try setting environment variable SLAVE_AAPT_TIMEOUT to a value bigger than 60 seconds
at com.android.builder.png.AaptProcess.waitForReady(AaptProcess.java:108)
at com.android.builder.png.QueuedCruncher$1.creation(QueuedCruncher.java:110)
at com.android.builder.tasks.WorkQueue.run(WorkQueue.java:203)
at java.lang.Thread.run(Thread.java:745)
//...[other repeated errors here]...
--- UPDATE: Please, see this other log of the external terminal used to run AS ---
What I've tried to solve that:
Install aapt system-wide;
Switch from Java 8 to Java 7;
Change gradle to off-line;
Change JDK configs to switch from the AS one to the system one;
Set SLAVE_AAPT_TIMEOUT to 30 (I changed back as you can see in the log link)
Set ANDROID_EMULATOR_FORCE_32BIT to true;
Install via ubuntu-make and also via ppa;
And so many others things I could find over Internet.
Environment specs
Linux Mint 18 (32 bits)
AS 1.5.1 (now (trying to use) 2.1.0)
Java Oracle 8 (Already tried the 7)
Why don't I just switch to Eclipse with plug-in
I have a course in mind (in Udacity) and they use that "thing" and it is a prerequisite. I've sent 3 e-mails to them questioning about the possibility of use other IDEs but without answer after 4 days, unfortunately.
Thank you so much for any help!
That error looks like your build tools aren't properly installed/set up. The aapt distributed with the build tools is versioned/linked with the tools, so studio probably isn't going to grab the random system level one. Have you attempted to install them, or did the older Studio version fail to prompt you to do so?
Beyond that, I'm afraid that Studio 1.4 is very deprecated and was missing many, many fixes that are in the newer versions, so it's somewhat likely that you would run into random errors with that version :-( What errors were you encountering with 2.2.1? It would be easier for the Studio team to help address those versus anything you find in 1.4.
My solution? Buy a 64 bits laptop! No installation error, no gradle error, no java error, no error anymore.
Problem
I'm attempting to create a Bitbake recipe which will install Oracle JRE 8 onto my target OS.
I've tried to use metadata from meta-oracle-java, but had some difficulties due to one of the .inc files which are provided for general JREs has a JRE-7-specific URI.
I've changed some of the metadata from meta-oracle-java and created my own recipe to do this install.
Tests
A Build of the JRE Recipe by Itself
When building the recipe by itself:
bitbake oracle-jse-jre
The build completes without error. I've added a dependency on libav into the oracle-jse-jre recipe, so I can do the following from TMPDIR:
$ find . -name libavformat*so
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54.20.4
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54
./sysroots/genericx86-64/usr/lib/libavformat.so.54.20.4
./sysroots/genericx86-64/usr/lib/libavformat.so
./sysroots/genericx86-64/usr/lib/libavformat.so.54
Runtime Dependency Success
If I add the default package from the oracle-jse-jre recipe to RDEPENDS_${PN} of another recipe xenoros_0.1.bb, I can run bitbake xenoros and build without errors.
Core Image Failure
If I add xenoros to the IMAGE_INSTALL variable of a core-image-xenoros, the build fails with the following error:
ERROR: Unable to install packages. Command '/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/sysroots/x86_64-linux/usr/bin/smart --log-level=warning --data-dir=/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/rootfs/var/lib/smart install -y message-generation#core2_64 catkin#core2_64 python-distutils#core2_64 ldd#core2_64 xenoros#core2_64 rosgraph#core2_64 gedit#core2_64 actionlib#core2_64 python-compression#core2_64 dhcp-server#core2_64 libpthread-stubs#core2_64 tf2#core2_64 python-email#core2_64 catkin-dev#core2_64 git#core2_64 rosbash#core2_64 python-json#core2_64 python-wstool#core2_64 connman#core2_64 ros-config#core2_64 packagegroup-core-boot#genericx86_64 libsdl-1.2-0#core2_64 rosjava#core2_64 quagga#core2_64 nginx#core2_64 rospy#core2_64 apt#core2_64 libc6#core2_64 netcat#core2_64 shadow#core2_64 bash#core2_64 roscpp#core2_64 roslaunch#core2_64 run-postinsts#all python-rosinstall#core2_64 elfutils#core2_64 openssl#core2_64 font-alias#all gradle#core2_64 python-catkin-pkg#core2_64 catkin-runtime#core2_64 catkin-runtime-dev#core2_64 pciutils#core2_64 base-passwd#core2_64' returned 1:
Loading cache...
Updating cache... ######################################## [100%]
Computing transaction...error: Can't install oracle-jse-jre-1.8.0-u77r0#core2_64: no package provides libavformat.so.53(LIBAVFORMAT_53)(64bit)
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/presslertj/yocto-OS/poky-jethro-build/build/tmip/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/temp/log.do_rootfs.22073
ERROR: Task 7 (/home/presslertj/yocto-OS/poky-jethro-build/meta-myLayer/recipes-core/images/core-image-my-server.bb, do_rootfs) failed with exit code '1'
Looking inside TMPDIR, I can find this:
/sysroots/genericx86-64/usr/lib/libavformat.so.54
It seems there's a version mismatch, where smart expects version 53, but 54 is provided.
Reverting libav's version
Just to test what's going on, I've made a recipe which fetches version 0.8.17 of libav (which uses version 53). When using this instead of 9.18, I have the exact opposite problem, that smart expects but can't find version 54.
Questions
How does smart determine the version number for these shared object files?
What about the do_rootfs() task causes the build to fail at this specific time?
Is there a simple resolution to my specific problem?
1) It's not smart, but rather rpmbuild, that is adding dependencies derived from the ELF DT_NEEDED field (see elfutils -a).
2) The do_rootfs() task is failing because of unresolved dependencies.
3) Since you are using Poky/Yocto and rpm5, there is a simple way to mask the issue (substituting whatever dependencies are causing you heartburn)
echo "unresoved_dependency" > /etc/rpm/sysinfo/Providename
That is just a band-aid; you still need to figure out the packaging issues rather than masking the underlying problem with how you are building rpm packages.
For anyone that still encounter this error: as stated in the README file of the meta-oracle-java repo
There are some known install problems for JRE packages due to dependencies reported by RPM package manager.
Switching to DEB or IPK packaging temporarily fixes this.
ie:
PACKAGE_CLASSES = "package_deb"
or
PACKAGE_CLASSES = "package_ipk"
in your 'local.conf' file