We Keep Coding

JavaFX Maven project in IntelliJ. JavaFX runtime components are missing only in IntelliJ. JAR through mvn package executes without issues

I have a Java Project with Spring Boot and JavaFX added through maven. The code compiles and even i can execute the fat jar without the JavaFX SDK in the computer. But when I try to execute it in IntelliJ it results in
Error: JavaFX runtime components are missing, and are required to run this application
I have seen this output in many questions and in most of those cases the jar wasn't built at all or code compilation failed.
But in this scenario the mvn package works with no errors and I can execute the JAR with java -jar <jar_name> to cross out the fact that I might have the javafx sdk installed somewhere I tried it in a VM with only the JRE installed.
pom.xml
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11.0.2</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>11.0.2</version>
</dependency>
As for plugins spring-boot-maven-plugin and maven-compiler-plugin.
Attempted Solutions
--1--
I tried the solution which said to add the
<plugin>
<groupId>org.openjfx</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>0.0.6</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<mainClass>com.example.demofx.Starter</mainClass>
</configuration>
</execution>
</executions>
</plugin>
But what it does is add the ability to run with: mvn clean javafx:run
The need to execute with IntelliJ is to debug the code because Debugging with souts isn't efficient.
--2--
Trying to module build with a module-info.jar with following
module com.example.demofx {
requires javafx.controls;
requires javafx.fxml;
// all other required modules including spring
opens com.example.demofx to javafx.fxml;
exports com.example.demofx;
}
This might have worked but due to some of old dependencies not working properly with modularized build this results in lots of breaking changes to the codebase.
Edit:
Missed to mention the environment
JDK - 11.0.8
IntelliJ IDEA - 2021.2.2
Added second solution tried.

This is more a troubleshooting and research guide than an actual fix. Fixes for environmental issues are difficult to provide in a StackOverflow context. However, if you study the information here, it might help you fix your project.
Recommended troubleshooting approach
Use the Intellij new JavaFX project wizard. Ensure that it works in your environment, then gradually add components from your current project into the working project, checking that everything still works after each small addition.
Debugging when executing via the JavaFX maven plugin
I think the above recommendation is the preferred approach, however, you can alternately get the following to work:
run with: mvn clean javafx:run
The need to execute with IntelliJ is to debug the code"
See:
intellij idea : how to debug a java:fx maven project?
I also think you can just right-click on the maven target for javafx:run and select Debug. I am not sure, I don't make use of the JavaFX maven plugin.
Creating fat jars for JavaFX applications
the fat jar
This is not a recommended configuration, but if you really must do it, you can review:
Maven Shade JavaFX runtime components are missing
That answer doesn't discuss getting such a configuration to work in conjunction with an Idea run/debug configuration, so it may not assist you.
If you do continue with a fat jar, I would not advise using a module-info, as you will be running code off the classpath anyway.
Modular versus non-modular JavaFX applications
If you don't use a fat jar, getting all the module dependencies correct for Spring is tricky anyway because Spring is not currently architected to directly support modules well. Spring 6 will be designed to work well with modules, though I think you should be able to get Spring 5 to work if you try hard enough (I have got it to work in the past for some applications).
Alternately you can just have the JavaFX components as modules and run the rest off the classpath. For example, the "Non-modular with Maven" approach at openjfx.io. Note that in that approach, the JDK and JavaFX modules are still loaded as modules off of the module path, it is only Spring your application that is not providing a module-info.java file and running off the classpath.
Creating runtime images for JavaFX applications
I also advise studying:
these resources for the creation of an appropriate runtime image.

Maven Jetty spams warning "scanned from multiple locations"

I've found a similar question here , but it points to a plugin that I'm not using (maven-failsafe-plugin), and the configuration that solution is referring to is not applicable for me.
The problem is that since I've updated my jetty plugin from
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.3.9.v20160517</version>
to <version>9.4.11.v20180605</version> , it started to spam hundreds of warnings like
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ClassReader scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class, jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.MethodTable scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/MethodTable.class, jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/MethodTable.class
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ParamNameExtractor scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1
I've searched everywhere but I can't understand neither what that means or how to resolve this.
I'm using IntelliJ and maven compiler plugin
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
Thanks

Lets break it down ...
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ClassReader scanned from multiple locations:
jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class,
jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class
You have the class org.apache.axis2.description.java2wsdl.bytecode.ClassReader coming from 2 different JARs (and seemingly on two different versions!)
Judging from your filesystem paths you likely have the following maven dependencies ...
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.4.1</version>
</dependency>
<dependency>
<groupId>it.aon.WSInfocar</groupId>
<artifactId>WSInfocar</artifactId>
<version>1.2</version>
</dependency>
It's unwise in the extreme to have two different versions of the same class on your classpath / classloader (it's very easy to have 1 version be used and then passed to a different class on the other version that will not understand it or be able to use it)
You'll need to resolve, manually, which one you should be using.
You might want to ask the developers of the WSInfocar why they are bundling axis in their own artifact as well.

I found this question and reply most helpful. I had a conflict with the JDT Core and the Java Eclipse compiler. I went to Properties and clicked on Java Compiler changing one thing at a time and testing. Changing from using JRE 1.8 to JRE 11 run time resolved it for me somewhere in all the things I tested.
I have checked:
Enable Project Specific Setting
Use Default Compliance Settings (1.8)
This puts up a notice:
When selecting 1.8 compliance be sure to have a compatible JRE installed and activated (currently 11). Configure the installed JRE or execution environment or change the build path.
Again, change one thing at a time then test. I specifically went with a 1.8 JRE because I read Java 11 does not ship a JRE. I am still not clear on that subject.

I find this problem solution all day, and if you want ignore the WARN log in jetty, you can try this:
--exec
-Dorg.eclipse.jetty.annotations.AnnotationParser.LEVEL=OFF
append these code in start.ini jetty file, and restart jetty.

2022 Update: the Pengwei method currently (Jetty 9) works by using this property:
java -Dorg.slf4j.simpleLogger.log.org.eclipse.jetty.annotations.AnnotationParser=ERROR ...
This can usually be injected into JVM via:
export JAVA_TOOL_OPTIONS="-Dorg.slf4j.simpleLogger.log.org.eclipse.jetty.annotations.AnnotationParser=ERROR"
run-java.sh # eg, catalina.sh
And also in Maven command line:
mvn -Dorg.slf4j...=ERROR
It is also possible to tweak Maven logging properties for all of your projects. However, that's not recommended, since, as already mentioned, these warnings might be relevant and a source of problems. In fact, as you see, I'm proposing to set at least the ERROR level, not to disable the scanner logger completely.

NoSuchMethodException: springframework.boot.autoconfigure.http.HttpMessageConverters

I want to use Java 9 with Spring. But I get exception:
Caused by: org.springframework.aop.framework.AopConfigException: Unable to instantiate proxy using Objenesis, and regular proxy instantiation via default constructor fails as well; nested exception is java.lang.NoSuchMethodException: org.springframework.boot.autoconfigure.http.HttpMessageConverters$$EnhancerBySpringCGLIB$$1d90bff9.<init>()
at deployment.datalis_gateway.war//org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:82)
at deployment.datalis_gateway.war//org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:205)
... 62 more
Caused by: java.lang.NoSuchMethodException: org.springframework.boot.autoconfigure.http.HttpMessageConverters$$EnhancerBySpringCGLIB$$1d90bff9.<init>()
at java.base/java.lang.Class.getConstructor0(Class.java:3302)
at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2512)
at deployment.datalis_gateway.war//org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:76)
... 63 more
Do you know how I can configure Java 9 to find this restricted Java package?

I came across the same error when trying to deploy a Spring Boot 2 application to Wildfly 13. This is the only Stack Overflow question that came up when I was searching for answers, so I thought I'd leave my findings here in case anyone else has the same issue, because my solution was very different from the only other answer here right now.
My application would run just fine using the embedded Tomcat server, but deploying to Wildfly would fail with the same AopConfigException asked about in this question. I also noticed in the root cause of the exception that Spring was looking for a no-arg constructor, and when I added no-arg constructors in all my autowired Spring components, the service actually deployed to Wildfly and ran with no problems. But this seemed like a hacky workaround that felt wrong, so I looked for a better solution.
I learned from this github issue that this exception happens in Wildfly because Jboss Modules are not exposing some dependencies needed by Objenesis to do constructor injection. The suggested solution they give is to add the dependencies by simply updating the project build as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Dependencies>jdk.unsupported</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
If this works for you, congratulations. I pieced together from this JBoss issue that the above solution is simply a way of adding "jdk.unsupported" as a "Dependency" in the MANIFEST.MF file. Unfortunately for me, this is part of a Maven pom, and my team uses Gradle for build management, so I had to find another solution.
Solution that works in Gradle OR Maven
Although there is probably a Gradle specific way to accomplish the above, I found from this JBoss development guide that you can add a dependency into the MANIFEST.MF using the jboss-deployment-structure.xml with the following contents:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
This seems like the preferred solution even if you do use Maven because it will work the same if you switch to Gradle down the road. Of course, this solution only works if the issue is isolated to JBoss/Wildfly.
*Note (in case the link to the JBoss guide goes down): jboss-deployment-structure.xml file goes in the WEB-INF or META-INF directory for a war/jar application respectively.
Also worth noting, I am seeing this issue on Java 11 and Wildfly 13, but I very strongly suspect that the same issue exists on Java 9 and 10 and on other versions of JBoss/Wildfly as well.

In my case VM argument --add-modules=jdk.unsupported helped. In this case ObjenesisCglibAopProxy creates a proxy using sun.reflect.ReflectionFactory and doesn't look for the absent constructor.

if you add jdk.unsupported as global module, you need not change the applications:
<global-modules>
<module name="jdk.unsupported"/>

You need to use a couple of --add-opens to your runtime JVM arguments and be prepared to add opens ... just about everywhere in your application that exposes something to the Spring context that isn’t exported yet.
More information

The issue seem to be with the java compiler version. I got this error when the compiled code was java version 11 and if I change the compiler to 8 I didn't see th

Which App Engine Maven Plugin to use?

been working with Google App Engine lately and stumbled upon something that is a mystery to me, maybe you can clarify.
According to some of Google's own websites (https://cloud.google.com/appengine/docs/java/tools/maven) you should use
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
and according to some other pages (https://cloud.google.com/appengine/docs/java/tools/maven-reference) you should use
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
Now I am really confused as to which I should use. Why are there two versions in the first place?
Problem I am facing:
The both seem to support different goals. One supports deploy etc. and the other one update and update_cron.
I need all 3 of those goals, any way I can have them with one dependecy?
Thanks in advance, hope someone can help me with this.
Sascha

<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
The first one is based on the previous (but not deprecated) appcfg (or Java SDK).
It offers a lot of Goals specific for App Engine, the basic ones with the dev-server and the deploy, but also for update queues, update cron, update indexes, vacuum indexes, ...
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
It's the newest one, still in beta. It is based on GCloud SDK and has a limited set of goals.
Here you can see the latest version from Maven Central, the latest one is 1.0.0, I don't see the 1.1.0-beta version
How to choose the proper plugin:
If you only need to use dev-server and deploy you can use the newest plugin based on GCloud SDK.
Those 2 goals are also available in the appcfg based plugin, but if you need more specific goals (like handling queue, cron, indexes, ...) are only available with this last one.
Also, the Google Cloud Endpoints goals, are only available to the appcfg one
At the end, those 2 plugin can coexists in the same project. The trick to use both of them is using the goal full path instead of the short one (source).
For example:
com.google.cloud.tools:appengine-maven-plugin:run
com.google.appengine:appengine-maven-plugin:devserver
And not
appengine:run
appengine:devserver
If you use the shorter version, Maven is unable to resolve the proper groupId (because the artifactId is the same on both plugins)
For the moment both plugins are operative and there is not trace of a deprecation about the appcfg based one.
Take me for example, I always use the deploy within the GCloud plugin (I consider it slighty better as deploy procedure compared to the appcfg one), but when I need to update cron/queues I use the goal of the previous plugin. I do not have any problem on having both on them inside my project
Remember that if you want to use the GCloud based one, you need to have GCloud installed (and configured) on your local machine.
Here is another thread which is discussing the same topic: `gcloud app deploy` vs. `appcfg.py`

The official documentation for both plugins is linked below:
com.google.appengine groupId
com.google.cloud.tools groupId
Both plugins are supported, they have the same artifactId (appengine-maven-plugin), but different goals and behave differently. I think this is another case of bad organization of a software evolution by Google. They could simply keep a single plugin and transparently move from one SDK to another by checking their existence in the environment, posting warnings/recommendations etc.

NetBeans emits message 'command line is too long'

I try to run my Java project and NetBeans reports that command line is too long.
Command line length is about 9900 chars long.
How this could be fixed?
I Use Vista 32 OS, NetBeans 6.9.1, jdk1.6.0_12
UPDATE:
It looks like this is connected with exec-maven-plugin (http://netbeans.org/bugzilla/show_bug.cgi?id=189137)

Same problem here - you must have a big classpath like I do. I wish the bug was higher than P3 so they'd patch it.
Easiest way to fix is to right click your project, choose Properties, then click Actions, scroll through the actions and find Run File via main() (or whatever action you're doing). Once you click that, you'll see that indeed it is using the 1.1.1 version of the maven exec plugin which has this bug. Just change the 1.1.1 to 1.2. Unfortunately, I think you'll have to do this for each project you run code from and for each action you use (run project, run via main, debug, etc). Hopefully someone knows a way to change this globally.

Have a look at this: http://support.microsoft.com/kb/830473
There is an explanation and ideas for workarounds...

I was having this problem with a maven Spring Boot based Java project and the solution for that case was to set fork to false in the Spring Boot plugin configuration.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<fork>false</fork>
</configuration>
</plugin>
I had the spring-boot-maven-plugin already in the project but I added the part below:
<configuration>
<fork>false</fork>
</configuration>
This is due to a change in Spring Boot to making forking the default.