I have one Jenkins job which does following things
Checks out the Jenkinsfile from github at some location (c:\jenkins\workspace\my_build)
Jenkinsfile checks out java source code to (c:\jenkins\workspace\my_build#2)
mvn clean install
When I run "mvn clean install" on my build machine it works perfectly fine.
But when I run it thorough Jenkisnfile I have few unit test cases which runs when building my project, those units tests are failing with java.io.FileNotFoundException(The system cannot find the path specified) exception/error.
When I ran maven in debug mode(using -X) I found out the workspace path(c:\jenkins\workspace\my_build#2) is being converted to c:\jenkins\workspace\my_build%402 hence maven is unable to find the file which is required for my unit test cases to pass.
How can I fix this issue?
I managed to fix the issue by using a custom workspace. Something like this
ws("c:\jenkins\my_custom_location") {
// git checkout
// mvn clean install
}
Jenkins didn't create any directory with #2 or #3 when using custom workspace.
#user3847894,
You did not fix the issue, merely worked around the problem (avoidance). Now, if you run builds in parallel, they will all use the same workspace, probably with horribly unintended consequences.
You can try choose a different symbol:
hudson.slaves.WorkspaceList
Since: 1.424 Default:
# Description: When concurrent builds is
enabled, a unique workspace directory name is required for each
concurrent build. To create this name, this token is placed between
project name and a unique ID, e.g. "my-project#123".
Or figure out the real problem:
where your system is pulling the wrong character set (ANSI vs UTF-8 ? locale), encoding or something is wrongly "sanitizing the path" (eg: OWASP Sanitizer).
You'd have to provide way more info re: OS, jdk, system and startup parameters, etc to diagnose, list of plugins (maven and Jenkins), so can't help further. Check controller and agent system info (${JENKINS_URL}/systemInfo and ${JENKINS_URL}/computer/myNode/systemInfo) and also see what maven reports in the settings and help:system. On your own; good luck
Related
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.
Are there caches or other environment files that can cause gradle to throw this error?
Exception in thread "main" java.lang.NullPointerException
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:34)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58)
I'm building a Jenkins CI server for building android apps. The Jenkins master passes the job off to an AWS linux slave, where it
Wipes the previous workspace
Downloads the github repo
moves into the project folder
./gradlew clean build
Then it throws the exception above.
Other repos using ./gradlew build on this machine.
This repo built prior to: adding additional disk space to the machine and downloading more android SDKs, neither of which should affect gradlew. Attempting to build the exact repo that built, with the same configuration that built still throws the same exception.
I added echoes to the gradlew file to see where the problem happens, and all of them sound prior to the final line:
exec "$JAVACMD" "${JVM_OPTS[#]}" -classpath "$CLASSPATH" org.gradle.wrapper.GradleWrapperMain "$#"
What do I need to do to make this build?
This took some hunting, but here is the solution that I found. Jenkins (by default) does not have access to the $PATH or any default applications (so that the computer can run Ruby 2.2 and your CI jobs can run Ruby 1.0 for example)
Iff you look in the script that is causing the error, it's because it calls a script which calls a script ect, until at some level down (I want to say 7) it calls the diff function. because this dependency was written assuming that your UNIX box knows the baked in applications. Because the Jenkins user calling this function doesn't know that this binary exists, and the way the entire script is written it throws the exception above.
Hope this helps
Something must be messing with your gradle wrapper setup. I would highly recommend the Jenkins Gradle Plugin. It has made my gradle builds trivial. You can specify any path to the build.gradle if it is not in the root workspace.
I wanted to try out the new feature of JMH by running it as Java Application in eclipse. I imported and built jmh-samples project. Compiled classes ended in /jmh-samples/target/generated-sources/annotations, there are several JARs in /target/ and running microbenchmarks.jar from command line works as usual.
However when I execute main I always get
No matching benchmarks. Miss-spelled regexp?
Any ideas? I am using version 0.3
jmh-dev# is a better way to communicate this with the developers.
Few things to try:
Hijacking Main is probably not a good idea. Use Java API instead, like this sample.
Use -v extra to debug the pattern matching: either the filter regexp is incorrect, or there are no benchmarks to run.
If the regexp is incorrect, fix it.
If there are no benchmarks to match against, then there is a chance resources are not generated and/or picked up properly. Make sure target/classes/ is also available on classpath.
Okay, so looks like by default jmh looks for generated classes under META-INF/Microbenchmarks, which maven build puts under root of the project. However root of the eclipse project is not on the classpath, so executing it in IDE results in "no benchmarks found".
I got it running following way:
mvn clean package (using external maven installation, not embded
in eclipse)
Right-click on jmh-samples project, select "Build
Path -> Use as a source folder"
You can now run any of the benchmarks from jmh-samples as Java Application in eclipse
On the downside you get like 1000+ "errors" in Problems view, since eclipse gets confused with auto-generated files, but oh well, at least it works.
I was also facing the same problem, and I followed the tutorial here. That solved the issue.
Below are the steps I took:
I used the code from the tutorial AS-IS to understand how it works.
Then I just did mvn clean and install
I saw all set of classes being created in target -> annotations -> <package path> -> generated
Then I ran the BenchmarkRunner main() class and this worked.
I wanted to try out the new feature of JMH by running it as Java Application in eclipse. I imported and built jmh-samples project. Compiled classes ended in /jmh-samples/target/generated-sources/annotations, there are several JARs in /target/ and running microbenchmarks.jar from command line works as usual.
However when I execute main I always get
No matching benchmarks. Miss-spelled regexp?
Any ideas? I am using version 0.3
jmh-dev# is a better way to communicate this with the developers.
Few things to try:
Hijacking Main is probably not a good idea. Use Java API instead, like this sample.
Use -v extra to debug the pattern matching: either the filter regexp is incorrect, or there are no benchmarks to run.
If the regexp is incorrect, fix it.
If there are no benchmarks to match against, then there is a chance resources are not generated and/or picked up properly. Make sure target/classes/ is also available on classpath.
Okay, so looks like by default jmh looks for generated classes under META-INF/Microbenchmarks, which maven build puts under root of the project. However root of the eclipse project is not on the classpath, so executing it in IDE results in "no benchmarks found".
I got it running following way:
mvn clean package (using external maven installation, not embded
in eclipse)
Right-click on jmh-samples project, select "Build
Path -> Use as a source folder"
You can now run any of the benchmarks from jmh-samples as Java Application in eclipse
On the downside you get like 1000+ "errors" in Problems view, since eclipse gets confused with auto-generated files, but oh well, at least it works.
I was also facing the same problem, and I followed the tutorial here. That solved the issue.
Below are the steps I took:
I used the code from the tutorial AS-IS to understand how it works.
Then I just did mvn clean and install
I saw all set of classes being created in target -> annotations -> <package path> -> generated
Then I ran the BenchmarkRunner main() class and this worked.
i've installed maven in my PC. and i've followed the instruction on this web http://books.sonatype.com/mvnref-book/reference/installation.html , but when i would try to run it in command line (as written), i've got BUILD FAILURE error just like this picture below.
How can i solve this problem? Thanks for any response
Btw, my other question, is there any documentation of configurating java application into guvnor? i'm so grateful if anyone knows about this. :)
You should specify a goal for the build. Check this for more info http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
You did not specify a goal for maven to run, so it does not know what to do with the project.
Maven relies on a certain lifecycle, ie an order of so called goals to accomplish its tasks, for example "clean" to empty the current target folder, "install" to compile, test, package and copy the jars into your local respository. To get into the details, read up this documentation.
Since the error message does not differ, another error might be that you entered the command in a folder where no valid pom file is located. If you entered a complete maven command with goals, this would be the next bet.