When I run mvn javadoc:javadoc, I get the following error:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An error has occurred in JavaDocs report generation:Exit code: 1 -
javadoc: error - cannot read options (The system cannot find the file specified)
Command line was:"C:\Program Files\Java\jdk1.6.0_14\jre\..\bin\javadoc.exe"
#options #packages
When I invoke the command "C:\Program Files\Java\jdk1.6.0_14\jre..\bin\javadoc.exe" on my system it runs the javadoc executable.
I am running:
JDK 1.6.0_14
Maven 2.0.8
The javadoc reporting part of my POM looks like:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
</plugin>
...
And relevant environment variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-2.0.8
M2_REPO=C:\Documents and Settings\<user>\.m2\repository //<user> is my user
MAVEN_OPTS=-XX:MaxPermSize=128m -Xmx512m
I have tried reinstalling Java and Maven, as well as using Maven 2.1.0, JDK 1.6.0_11, and even JDK 1.5.0_11. I have compared my setup to a coworker who has practically the same environment but no problems. It used to work about a month ago, and no, I don't know what's changed on my system since then. I first encountered it with JDK 1.6.0_11. This happens on every project I've tried in our repository, and my coworkers have no problems with the same projects. So I'm pretty sure it's just my environment and not the projects themselves.
I would really appreciate any suggestions on this.
I figured it out, but first I tried various things:
Uninstalling every JDK and JRE on my system, and then reinstalling Java to a path with no spaces
Removing every environment variable I wasn't using, and cleaning up my PATH
Relocating Maven and my local repo to directories with no spaces
Rebooting (you never know, it's Windows)
Today I tried to run a batch file which didn't execute properly, and I quickly realized that when I double clicked on it, it was executing the file but not in the directory where it lived. And then it hit me.
A few weeks ago I got fed up with our IT guys forcing our cmd window to open at H: and so I Googled and used this page to "fix it". It seemed to work; I didn't have any problems for a few weeks and I had already forgotten that my cmd windows all used to open to some H: drive. But every single cmd window opened to a directory I specified--whether I ran "cmd" or clicked a batch file or if Maven opened a new cmd window...
I guess when Maven runs it shells out to execute the javadoc command. And so the javadoc part was working, but it couldn't find the options file it writes out because the working directory was wrong.
So, now I'm back on H: until I can figure that out. And then I'll screw something else up. But hopefully, if nothing else, this will help someone else...
I believe the problem is that the javadoc command is being run without any parameters. I ran into this in one of my multi-module projects where it was trying to javadoc a non-java module. (The javadoc was being requested by the parent, pom.)
Does the module in question have javadocs to be made? We finally moved to maven 2.1.0 and I haven't seen the problem reoccur.
Are your other team members also using maven 2.0.8?
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.
In Eclipse I am using JavaFX, Maven with jre 1.8.0_45.
Normally, when I try to compile with Maven this way (Run As -> Maven compile) it will throw an error for not using the jdk.
When I change it to jdk (everywhere like in configuration, window - properties, maven configuration) and try to run/build/compile/whatever I get the error
Error: Could not find or load main class
Without giving me any class up there. Just this.
I kind o' fixed this by adding to my pom the path to javac and staying with the jre package
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler.version}</version>
<configuration>
<!-- With JRE: -->
<fork>true</fork>
<executable>C:\Program Files\Java\jdk1.8.0_45\bin\javac.exe</executable>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
This works.
But still I wish to know - why is this error happening? What am I doing wrong?
I've used Project -> Clean and Maven -> Update. Restarted Eclipse many times. Closed and opened the project.
My Main class is given in my Run Configuration (application.Main).
EDIT:
Resolved. Answered my (own) question below.
Hey Pleased set the path environment variable mentioning the installtion path of java.
https://www.java.com/en/download/help/path.xml
Could not find or load main class HelloWorldApp.class
A common mistake made by programmers is to try and run the java launcher on the .class file that was created by the compiler. For example, you'll get this error if you try to run your program with java HelloWorldApp.class instead of java HelloWorldApp. Remember, the argument is the name of the class that you want to use, not the filename.
Resource Link:
https://docs.oracle.com/javase/tutorial/getStarted/problems/
https://bbs.archlinux.org/viewtopic.php?id=187463
I managed to resolve the problem.
What I did was a uninstall and a clean install of jdk, a clean install of eclipse and all eclipse plugins I was using.
Possible reasons for the problem:
Some path problem and/or confusion in jdk/jre versions. #Lokesh Nandanwar was close.
Some kind of eclipse problem, don't know what though
Thank you for your answers. Usually this is a CLASSPATH problem, but not this time.
Conclusion is:
If the Error is "Could not find or load main class SomeMainClass.class" you have a classpath problem or have not used java(c) command line properly. See #SkyWalker 's suggestions.
In Eclipse "refreshment" is needed. Close and open the project, clean the project, etc.
With Maven+Eclipse the reason could be wrong path to Main class given in the POM file.
If the error is just "Could not find or load main class", something's messed up with the environment.
I also ran into same issue. by default JRE libraries are also added under libraries tab in "Buildpath panel of project properties in eclipse. still it was giving me same error when I build application as standalone java application. But later I found that JRE is not checked under "Order and Export" tab (next to the libraries tab). So, I just checked it and build application. it is working now.
One of the reasons can be :
Mistakenly you have added multiple version of JRE system Library.
I have just run into the Apache Ivy bug java.lang.ClassCastException: org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 cannot be cast to java.lang.String (link) when performing Ant task ivy:config
This morning I tried to install LibraryFolder ClasspathContainer plugin into my Eclipse (STS 3.6.1): installing it caused the above error every time I tried to perform ivy:retrieve.
Even worse, I tried to install IvyDE plugin from Eclipse Marketplace and Eclipse started to crash at a multitude of errors, including JVM crash. Uninstalling both plugins didn't fix. I tried with a new workspace and a blank Eclipse installation, but I eventually had to install my previous Eclipse plugins.
I spent the entire morning trying to fix the mess but I had to restore the previous uncommitted workspace and Eclipse installation, so now I get everything working except for the above error. Ivy worked fine until this morning.
Every Ant task of mine runs in the same JRE as Eclipse (C:\Program Files\Java\jdk1.7.0_60\jre\bin\server\jvm.dll as per sts.ini) because I use a lot the eclipse.refreshLocal task. While I can workaround the problem by removing/commenting eclipse.refreshLocal task and run Ant-Ivy tasks in a standard JRE, I'm asking if there is a workaround to get rid of the error, perhaps by deleting a key file in the workspace's metadata.
As I can read, an Ivy method is passed an object that, guessing from its name, is part of Eclipse configuration. While I'll be waiting for a bugfix, my question is how do I investigate more about the nature of this org.eclipse.osgi.internal.framework.EquinoxConfiguration$1 parameter?
This looks related to Error at building model of new Gradle project for libgdx - which includes a workaround that works for Gradle IDE, so maybe it will work for you.
The relevant Eclipse bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122
[Edit by OP] to simplify life to people having the same problem I'll post the contents of the link and accept the answer
Just add the following lines to eclipse.ini
-Dorg.eclipse.swt.browser.IEVersion=10001
-Dosgi.configuration.area.default=null
-Dosgi.user.area.default=null
-Dosgi.user.area=#user.home
-Dosgi.instance.area.default=null
I have JDK8 installed in the directory C:\Program Files\Java\jdk1.8.0_05\ and I have my PATH Environment Variable set to C:\Program Files\Java\jdk1.8.0_05\bin.
Now; in order to use Amazon's Product API I follow their guidelines here under the Java getting set up section; and I use the following command...
wsimport -d ./build -s ./src -p com.ECS.client.jax http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl -b jaxws-custom.xml
after opening a command prompt in a custom directory I created on my desktop; that custom directory contains the build and src directories as specified in the instructional page provided by Amazon.
Now when I run the command aforementioned; I receive the error...
'wsimport' is not recognized as an internal or external command
however; if I run Java -version within the same command prompt all works well and as expected.
Not sure where to go from here or why it isn't reading through?
Note I already attempted the solutions at this page; to no avail.
I found this in the comments section of the following article. I include it here in full because I think it explains why your JDK8/wsimport fails to build and consequently why it works when you switch back to Java7.
http://blog.takipi.com/6-reasons-not-to-switch-to-java-8-just-yet/
Even though the article was written over 3 years ago, I am still having java8/wsimport problems (2017).
Why not mention some more obvious ones:
The new defaults in Javadoc (called doclint) will break your build. In particular if you are using Maven and some kind of CI (e.g. Hudson,
Jenkins) you'll quickly realize that you can't just take your project
and build in JDK8. Your build will almost certainly error out because
of the new Javadoc. (I have yet to see a project that didn't). The
reason is that in Maven a return error code from the javadoc tool will
stop the whole release process ... and as I said I have yet to see a
project that would not somewhere have a Javadoc doclint noncompliance.
Most larger projects (e.g. Netty) seem to solve the problem by simply
turning off doclint (which of course wasn't the idea behind doclint)
or they stay on JDK7 for a while longer until they iron out all their
comments problems.
Code generation tools in JDK8 (e.g. wsimport) produce code that is not doclint compliant. This is a clear bug and well documented. It
means that one part of the JDK8 is not working with another part of
the JDK8. Expect to have to circumvent this somehow if you have a web
consumer application.
Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?
After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.
It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.