What are the possible causes of a "java.lang.Error: Unresolved compilation problem"?
Additional information:
I have seen this after copying a set of updated JAR files from a build on top of the existing JARs and restarting the application. The JARs are built using a Maven build process.
I would expect to see LinkageErrors or ClassNotFound errors if interfaces changed. The above error hints at some lower level problem.
A clean rebuild and redeployment fixed the problem. Could this error indicate a corrupted JAR?
(rewritten 2015-07-28)
Summary: Eclipse had compiled some or all of the classes, and its compiler is more tolerant of errors.
Long explanation:
The default behavior of Eclipse when compiling code with errors in it, is to generate byte code throwing the exception you see, allowing the program to be run. This is possible as Eclipse uses its own built-in compiler, instead of javac from the JDK which Apache Maven uses, and which fails the compilation completely for errors. If you use Eclipse on a Maven project which you are also working with using the command line mvn command, this may happen.
The cure is to fix the errors and recompile, before running again.
The setting is marked with a red box in this screendump:
try to clean the eclipse project
you just try to clean maven by command
mvn clean
and after that following command
mvn eclipse:clean eclipse:eclipse
and rebuild your project....
Your compiled classes may need to be recompiled from the source with the new jars.
Try running "mvn clean" and then rebuild
The major part is correctly answered by Thorbjørn Ravn Andersen.
This answer tries to shed light on the remaining question: how could the class file with errors end up in the jar?
Each build (Maven & javac or Eclipse) signals in its specific way when it hits a compile error, and will refuse to create a Jar file from it (or at least prominently alert you). The most likely cause for silently getting class files with errors into a jar is by concurrent operation of Maven and Eclipse.
If you have Eclipse open while running a mvn build, you should disable Project > Build Automatically until mvn completes.
EDIT:
Let's try to split the riddle into three parts:
(1) What is the meaning of "java.lang.Error: Unresolved compilation
problem"
This has been explained by Thorbjørn Ravn Andersen. There is no doubt that Eclipse found an error at compile time.
(2) How can an eclipse-compiled class file end up in jar file created
by maven (assuming maven is not configured to used ecj for
compilation)?
This could happen either by invoking Maven with no or incomplete cleaning. Or, an automatic Eclipse build could react to changes in the filesystem (done by Maven) and re-compile a class, before Maven proceeds to collect class files into the jar (this is what I meant by "concurrent operation" in my original answer).
(3) How come there is a compile error, but mvn clean succeeds?
Again several possibilities: (a) compilers don't agree whether or not the source code is legal, or (b) Eclipse compiles with broken settings like incomplete classpath, wrong Java compliance etc. Either way a sequence of refresh and clean build in Eclipse should surface the problem.
I had this error when I used a launch configuration that had an invalid classpath. In my case, I had a project that initially used Maven and thus a launch configuration had a Maven classpath element in it. I had later changed the project to use Gradle and removed the Maven classpath from the project's classpath, but the launch configuration still used it. I got this error trying to run it. Cleaning and rebuilding the project did not resolve this error. Instead, edit the launch configuration, remove the project classpath element, then add the project back to the User Entries in the classpath.
I got this error multiple times and struggled to work out. Finally, I removed the run configuration and re-added the default entries. It worked beautifully.
Just try to include package name in eclipse in case if you forgot it
Import all packages before using it, EX: import java.util.Scanner before using Scanner class.
These improvements might work and it will not give Java: Unresolved compilation problem anymore.
Also make sure to check compiler compliance level and selected jdk version is same
As a weird case, I encountered such an exception where the exception message (unresolved compilation bla bla) was hardcoded inside of generated class' itself. Decompiling the class revealed this.
I had the same issue using the visual studio Code. The root cause was backup java file was left in the same directory.
Removed the backup java file
When the build failed, selected the Fix it, it cleaned up the cache and restarted the workSpace.
I have been searching for long a blog or so which explains how to add grpc to my project. The best on I found was that: https://medium.com/swlh/using-grpc-with-kotlin-for-building-microservices-2a79d95a236a
Unfortunaly the steps in here are not clearly explained. Eg. where should the proto files be loctated and where should I import the Protobuf Compiler exactly (for what do I really need it?).
Error:
Execution failed for task ':stub:extractIncludeProto'.
> Could not resolve all files for configuration ':stub:compileProtoPath'.
> Could not find io.grpc:grpc-kotlin-stub:1.1.0-SNAPSHOT.
Searched in the following locations:
- file:/C:/Users/David/.m2/repository/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/maven-metadata.xml
- file:/C:/Users/David/.m2/repository/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/grpc-kotlin-stub-1.1.0-SNAPSHOT.pom
- https://repo.maven.apache.org/maven2/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/maven-metadata.xml
- https://repo.maven.apache.org/maven2/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/grpc-kotlin-stub-1.1.0-SNAPSHOT.pom
- https://dl.google.com/dl/android/maven2/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/maven-metadata.xml
- https://dl.google.com/dl/android/maven2/io/grpc/grpc-kotlin-stub/1.1.0-SNAPSHOT/grpc-kotlin-stub-1.1.0-SNAPSHOT.pom
Required by:
project :stub
Possible solution:
- Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
The base problem is probably that all grpc tutorials are based on this github repository and I cannot compile any project from the examples folder. The proplem there is that gradle could not find the proto-project even though it is there (in my opinion).
So I decided to ask you, if some one has a link or knowlege about how to make a simple grpc server with the base of an empty Kotlin/JVM Application.
Sorry for this simple question, but this really upsets me that this just won't work
Replace grpc-kotlin-stub version from 1.1.0-SNAPSHOT to 1.1.0; Beacuse snapshot can't find in those repositories. Or you should install 1.1.0-SNAPSHOT to local maven repo first by using mvn install in grpc-kotlin-stub project.
As shown in the screenshot there is a dependency of the dl4j-0.4-examples project that is unable to be loaded by intellij.
Unable to get dependency information: Unable to read the metadata file
for artifact 'com.github.jai-imageio-core.jar': Invalid JDK version in
profile "java8-and-higher': Unbounded range [1.8
A similar problem resolved in this question
https://github.com/google/gson/issues/596
as quick fix open the pom file at your local repository and add ')'
and should looks like
91 [1.8,)
save and execute again
But in this case there is no jdk tag: so that approach can not be used.
Has anyone found a workaround to load this project into intellij?
The owners of the project have recognized this as an issue. If you would like to follow along here is the bug tracker:
https://github.com/deeplearning4j/dl4j-0.4-examples/issues/76
Update 2/28/16: The resolution: I needed to do
brew switch maven 3.3.9
There were multiple versions of maven installed on my machine but I did not know about brew switch. So some ways maven was working without doing the switch - but for this project a completely clean maven installation was required.
I'm using PMEase QuickBuild to perform automated builds of our Maven2 projects and a nightly sanity test to ensure nothing is broken.
The test needs to untar packages which are created by the automated Maven2 projects. The problem is that the package names change frequently due to project versions being incremented all the time.
Does anyone know how I can configure QuickBuild to pick up the version (ideally from the POM file of the individual components), if this is possible at all?
I don't know if this is an option for you but it looks like you can do it the other way around. Quoting Build with Maven:
Control build version
If you want to control the build
version from QuickBuild side, please
follow below steps:
Change the POM file and define the project version as
${buildVersion}. Do not forget to
commit the file into your SCM after
change.
Define a build property like below when define the Maven build
step:
buildVersion=${build.version}
There are maybe other options but I must admit that my knowledge (zero) of QuickBuild is very limited
I created a work around to this issue by having QuickBuild execute a shell script which did the untarring by using wildcards, similar to the following (to avoid computing the exact version):
tar xzf filename-*.tar.gz
I couldn't figure out how to do this in QuickBuild, so I offloaded the work to the shell script.
I'm building Maven projects via TeamCity/Git and trying to insert the TeamCity build numbers in the pom.xml that gets published to my repository upon a successful build. Unfortunately I can't determine how to publish a pom.xml with the substitutions inserted.
My pom.xml contains info like:
<version>${build.number}</version>
where build.number is provided by TeamCity. That all builds ok, and if (say) build.number = 0.1, then the deployment is a pom.xml to a directory with 0.1. All well and good.
However, the pom.xml that is deployed is the pom.xml without the substitutions made. i.e. Maven is running with a pom.xml with appropriate substitutions, but deploys the initial version and so I get
<version>${build.number}</version>
in the final pom.xml. How can I get the build version number in the pom.xml ?
I wouldn't use this approach because it makes building a project checked out from the SCM not possible without providing the build.number property. I don't think that this is a good thing. Maybe I'm missing something though.
Actually, I don't get what you are trying to achieve exactly (why don't you write the build number in the manifest for example). But, according to the Maven Features on the Teamcity website:
By default, it also keeps TeamCity build number in sync with the Maven version number (...).
Couldn't that be helpful? There is another thread about this here.
Try to use generateReleasePoms property of maven-realease-plugin, maybe that helps a little.