Develop Reference

Fatal error compiling: java.lang.NoClassDefFoundError: com/sun/tools/javac/main/OptionName: com.sun.tools.javac.main.OptionName

I am supporting java based Application which using (JSP + Spring + Hibernate). We are using Maven to build the code. The servers where application is deployed is now come under EOSL, so now we need to upgrade the server which will non EOSL. In application we are currently using JDK jdk1.6.0_45
and tomcat 7.0.107.Now I need to enhance the JDK from jdk1.6.0_45 to JDK jdk-11.0.12 but while I am changing the JDK jdk-11.0.12 during project build process I am getting error like "Fatal error compiling: java.lang.NoClassDefFoundError: com/sun/tools/javac/main/OptionName: com.sun.tools.javac.main.OptionName".
Note : While I am switching to JDK 7 then error gone but I need only to run code on JDK 11. Please help me. What are the action I need to take.
Maven version :
C:\Users\vtripath\Desktop\4C\workplace\cosmo>mvn -version
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: C:\Program Files\apache-maven-3.8.1\bin\..
Java version: 11.0.12, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-11.0.12
Default locale: en_IN, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Error:
ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project cosmo-core: Fatal error compiling: java.lang.NoClassDefFoundError: com/sun/tools/javac/main/OptionName: com.sun.tools.javac.main.OptionName -> [Help 1]
[ERROR]

Maven is using wrong java version

I am trying to build a maven project on centOS 8. I want maven to use Java version 15. When I run mvn package I get the following error:
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
(default-compile) on project systembrett-backend: Fatal error compiling: invalid target release: 15 -> [Help 1]
So I suspect that maven is using the wrong Java version, because when i do mvn package -X for debug logs it start with:
Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 1.8.0_275, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.275.b01-1.el8_3.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.18.0-240.1.1.el8_3.x86_64", arch: "amd64", family: "unix"
so it looks like, maven is using Java version 1.8.
But mvn -version says:
Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 15.0.2, vendor: AdoptOpenJDK, runtime: /opt/jdk-15.0.2+7
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.18.0-240.1.1.el8_3.x86_64", arch: "amd64", family: "unix"
JAVA_HOME is /opt/jdk-15.0.2+7 and PATH is /opt/jdk-15.0.2+7/bin:/home/username/.local/bin:/home/username/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin.
I thought maven is choosing the java version by checking JAVA_HOME, but apparently it is using an other version for the build. Does anyone know how to tell maven the correct version?
Thanks!

Following is a list of steps I use to troubleshoot this kind of issues:
Linux usually works with alternatives to ensure proper default Java environment is used. Similar to:
$ alternatives --config java
There are 2 programs which provide 'java'.
Selection Command
-----------------------------------------------
+ 1 java-1.7.0-openjdk.x86_64 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.191-2.6.15.4.el7_5.x86_64/jre/bin/java)
* 2 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/jre/bin/java)
Try also for javac as it may not be configured the same way:
$ alternatives --config javac
For your maven instance, JAVA_HOME should be enough.
Your output of mvn -version testifies that you have configured it correctly. Remove your Java from your PATH to ensure JAVA_HOME and mvn will find the correct one.
The pom.xml can also configure the required compiler, similar to:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
Another thing may be that you're not using the same ENV (different terminals may not have the same environment variables exported - I presume you being on CentOS, you already encountered this). You have to exit the terminal and get back in to allow the default variables to take effect.
You encounter this usually when different JRE vs JDK are used ( more: maven installation has runtime as JRE instead of JDK )

I had the same issue on RHEL 9.1. The solution was to look at /etc/java/maven.conf and set the correct JAVA_HOME here in this file.

Building Apache Roller on Windows 7

I am getting this kind of error when i tried to build apache roller on my windows 7 service pack 1 64 bit.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (gen-db-scripts) on project roller-webapp: An Ant BuildException has occured: Exception thrown by 'generator.parse'. For more information consult the velocity log, or invoke ant with the -debug flag.
[ERROR] around Ant part ...<texen outputFile="README.txt" controlTemplate="control.vm" outputDirectory="F:\roller-trunk\app/target/dbscripts" templatePath="F:\roller-trunk\app/src/main/resources/sql" contextProperties="F:\roller-trunk\app/src/main/resources/sql/dbscripts.properties"/>... # 5:261 in F:\roller-trunk\app\target\antrun\build-main.xml: F:\roller-trunk\app\target\dbscripts\db2\createdb.sql (The system cannot find the path specified)
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (gen-db-scripts) on project roller-webapp: An Ant BuildException has occured: Exception thrown by 'generator.parse'. For more information consult the velocity log, or invoke ant with the -debug flag.
around Ant part ...<texen outputFile="README.txt" controlTemplate="control.vm" outputDirectory="F:\roller-trunk\app/target/dbscripts" templatePath="F:\roller-trunk\app/src/main/resources/sql" contextProperties="F:\roller-trunk\app/src/main/resources/sql/dbscripts.properties"/>... # 5:261 in F:\roller-trunk\app\target\antrun\build-main.xml
i suspect this outputDirectory="F:\roller-trunk\app/target/dbscripts" templatePath="F:\roller-trunk\app/src/main/resources/sql"` is the problem but i have no idea how to fix it. I ran the "mvn clean install" from my command prompt.

I succeeded building Roller source code in current SVN trunk (5.2.0-SNAPSHOT) on Windows 7 box without errors. output of mvn -version is following:
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T20:57:37+09:00)
Maven home: c:\apache-maven-3.3.3
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_45\jre
Default locale: ja_JP, platform encoding: MS932
OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
Could you try building with same version of JDK/Maven to the above output?
UPDATE
Now GitHub distribution of Roller can be built without this error. For detail check https://issues.apache.org/jira/browse/ROL-2086

GitHub doesn't store the empty directories that Roller needs to do the build, if this patch were applied (https://github.com/apache/roller/pull/3) the problem would be fixed.
My work-in-progress Github fork of Roller, TightBlog, already has this change in place: https://github.com/gmazza/tightblog. But TightBlog is not ready for regular use.

I believe this error happens because of direct pull from the Github version. At first, I've tried to pull it from Github and I faced the same problem. Later on, I've tried to checkout it directly from the SVN trunk and there's no problem with the building process.
I believe this error has also been described previously at http://comments.gmane.org/gmane.comp.java.roller.devel/5895. It is stated that there might be some problems with the Github version.

Cannot access DisposableBean and cannot access InitialzingBean

I'm trying to compile the oVirt open source project on fedora core 21,
java -version
openjdk version "1.8.0_20"
OpenJDK Runtime Environment (build 1.8.0_20-b26)
OpenJDK 64-Bit Server VM (build 25.20-b23, mixed mode)
I am getting the following errors:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project builtin: Compilation failure: Compilation failure:
[ERROR] /home/jenkins/workspace/ovirt-engine_master_find-bugs_merged_nomvn/ovirt-engine/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/utils/ipa/SimpleAuthenticationCheck.java:[61,25] error: cannot access InitializingBean
[ERROR] /home/jenkins/workspace/ovirt-engine_master_find-bugs_merged_nomvn/ovirt-engine/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[145,31] error: cannot access DisposableBean
mvn -version shows :
mvn -version
Apache Maven 3.2.2 (NON-CANONICAL_2014-06-19T11:19:24_mockbuild; 2014-06-19T11:19:24+00:00)
On fedora core18 it works -
Apache Maven 3.0.4 (rNON-CANONICAL_2013-04-08_07-49_mockbuild; 2013-04-08 10:49:23+0300)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.9.11-200.fc18.x86_64", arch: "amd64", family: "unix"
The spring that is being used is aligned to 3.1.1.RELEASE from what I can see
In both the machines.
Can you give a hand? I know I'm using code that implements InitialzingBean and DisposableBean, but still - if same spring version, how come it does not compile

we had this problem and we had installed JDK 1.8. When we installed JDK 1.7 then this issue disappeared. Try it, maybe it is your case :)

Why isn't maven replacing the environment variable for the maven-release-plugin release version?

I am trying to use the maven-release-plugin with some environment variables, but I get an issue when I use an environment variable for the release version.
I am executing:
mvn release:clean --batch-mode -Dtag=${env.tag} -Dproject.rel.com.mycompany.project:project-root=${env.project.rel.com.mycompany.project:project-root} -Dproject.dev.com.mycompany.project:project-root=${env.project.dev.com.mycompany.project:project-root} release:prepare
I am getting:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare
(default-cli) on project project-root: Error parsing version,
cannot determine next version: Unable to parse the version string:
"${env.project.rel.com.mycompany.project:project-root}" -> [Help 1]
If I change the ${env.project.rel.com.mycompany.project:project-root} to a specific version, the command will pass.
But as you can see I am using:
${env.tag}
${env.project.dev.com.mycompany.project:project-root}
with no issues. Is this a bug? Or am I doing something wrong?
Additional notes:
Environment variables:
tag=2.55
project.rel.com.mycompany.project:project-root=2.55
project.dev.com.mycompany.project:project-root=2.56-SNAPSHOT
My Maven version is:
C:\>mvn -version
C:\>set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=512m
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Users\John\Documents\apache-maven-3.0.4-bin
Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
Java home: C:\JDK\jdk1.6.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

you will have to use the arguments attribute: http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#arguments
So in your context your cmd line will look like this (Note the double quotes as well):
mvn release:clean --batch-mode release:prepare "-Darguments=-Dtag=${env.tag} -Dproject.rel.com.mycompany.project:project-root=${env.project.rel.com.mycompany.project:project-root} -Dproject.dev.com.mycompany.project:project-root=${env.project.dev.com.mycompany.project:project-root}"
Furthermore, if i remember right the uses of the tokens ${env.X} requires the usage of the property name in upper case (to be verified)

It's not working because the release plugin clears the environment[1]. I doubt it's documented[2], I found out by looking at the source. Farid's answer is a good workaround - it passes the environment value via java properties which are not cleared.
I would have simply commented on Farid's answer but SO doesn't think I'm shiny enough.
Why??
Classic maven.