Getting bundle exception while deploying app to Apache Karaf - apache-karaf

I'm developing simple application to demonstrate use of Apache Karaf.I have developed one simple maven based dynamic web project in eclipse.Now I want to deploy it in apache karaf.Following is that code-
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
public class DemoActivator implements BundleActivator {
#Override
public void start(BundleContext bundleContext) throws Exception {
System.out.println("STARTING DEMO: hello, world");
}
#Override
public void stop(BundleContext bundleContext) throws Exception {
System.out.println("STOPPING DEMO");
}
}
Dependancies in POM.Xml
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_core</artifactId>
<version>1.0</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_compendium</artifactId>
<version>1.0</version>
<scope>provided</scope>
<optional>true</optional>
</dependency>
MANIFEST.MF
Bundle-SymbolicName: osgi-example
Bundle-Version: 1.0.0.SNAPSHOT
Import-Package:com.psl.demo;version="1.0.0.SNAPSHOT",org.osgi.framework
Export-Package: com.psl.demo;version="1.0.0.SNAPSHOT"
Bundle-Activator: com.psl.demo.DemoActivator
Given path of custom MANIFEST file
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
</build>
Now whenever I'm trying to install application in karaf using-
install mvn:com.psl/osgi-demo-next/1.0.0-SNAPSHOT
Im getting error as-
Error executing command: Error installing bundles: Unable to install
bundle mvn:com.psl.demo/osgi-example/1.0.0.SNAPSHOT:
org.osgi.framework.BundleException: Unable to cache bundle:
mvn:com.psl.demo/osgi-example/1.0.0.SNAPSHOT
Any solution for this? TIA

This error is coming because maven coordinates in bundle install command are not correct. Following is syntax for the same:
karaf#root()> bundle:install mvn:<group-id>/<artifact-id>/<version>
Please validate the content of pom.xml and accordingly put values in above command.
From simplicity perspective, you could check local maven repository to find bundle location and accordingly put values in above bundle install command.

Related

jlink showing error while comparing hashes

I am currently trying to bundle a javaFx test application via maven and jlink into a runtime image. I am using bellsoft liberica 18.0.1 as a jdk and I am running on a IntelliJ IDE. I have used the IDE to setup the project initially (via the wizzard). If I hit javafx:run, everything fires up correctly, the application is displayed and all is fine.
However, running javafx:jlink produces the following error:
Error: Hash of javafx.base
(d775513043c11c457939b41e544cc7a83a4076454da4a0798bdc6922ec7d3f8f)
differs to expected hash
(eb1d4f72b292e9bf33005b36c4afeda11b66a8745b868bf0593d1cd4c2974681)
recorded in java.base java.lang.module.FindException: Hash of
javafx.base
(d775513043c11c457939b41e544cc7a83a4076454da4a0798bdc6922ec7d3f8f)
differs to expected hash
(eb1d4f72b292e9bf33005b36c4afeda11b66a8745b868bf0593d1cd4c2974681)
recorded in java.base
This appears odd, as I am unsure which hashes are compared at that point. I have tried executing jlink with --fail-never as well as --lax-checksums and ignoreSigningInformation, but nothing appears to help. I have also tried to check the sha-checksums from within my m2-Repository, but I can't nail it down that way either.
Any help to sort this out is much appreciated.
EDIT: Including the current pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>myapp</artifactId>
<version>1.0-SNAPSHOT</version>
<name>myappMavenModulebased</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<junit.version>5.9.1</junit.version>
</properties>
<dependencies>
<!-- https://mvnrepository.com/artifact/org.openjfx/javafx-base -->
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>19</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>19</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>19</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-web</artifactId>
<version>19</version>
</dependency>
<dependency>
<groupId>org.controlsfx</groupId>
<artifactId>controlsfx</artifactId>
<version>11.1.2</version>
</dependency>
<dependency>
<groupId>com.dlsc.formsfx</groupId>
<artifactId>formsfx-core</artifactId>
<version>11.5.0</version>
<exclusions>
<exclusion>
<groupId>org.openjfx</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>net.synedra</groupId>
<artifactId>validatorfx</artifactId>
<version>0.3.1</version>
<exclusions>
<exclusion>
<groupId>org.openjfx</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.kordamp.ikonli</groupId>
<artifactId>ikonli-javafx</artifactId>
<version>12.3.1</version>
</dependency>
<dependency>
<groupId>org.kordamp.bootstrapfx</groupId>
<artifactId>bootstrapfx-core</artifactId>
<version>0.4.0</version>
</dependency>
<dependency>
<groupId>eu.hansolo</groupId>
<artifactId>medusa</artifactId>
<version>16.0.1</version>
<exclusions>
<exclusion>
<groupId>org.openjfx</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<!-- Build an executable JAR -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.test.myapp.AppLauncher</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
<configuration>
<source>18</source>
<target>18</target>
</configuration>
</plugin>
<plugin>
<groupId>org.openjfx</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>0.0.8</version>
<executions>
<execution>
<!-- Default configuration for running with: mvn clean javafx:run -->
<id>default-cli</id>
<configuration>
<mainClass>com.test.myapp/com.test.myapp.HelloApplication</mainClass>
<launcher>app</launcher>
<jlinkZipName>app</jlinkZipName>
<jlinkImageName>app</jlinkImageName>
<noManPages>true</noManPages>
<stripDebug>true</stripDebug>
<noHeaderFiles>true</noHeaderFiles>
<failNever>true</failNever>
<ignoreSigningInformation>true</ignoreSigningInformation>
<jlinkExecutable>/home/user/.jdks/bellsoft-jdk19.0.1/bin/jlink</jlinkExecutable>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
EDIT 2: I am providing the jlink-Tool in the pom.xml. My idea was that doing it this way, jlink would be able to create the runtime image based on the liberica-jdk. Is the problem that I am using openjfx-dependencies with the liberica-jlink-Tool?
What the problem is
The module hash mismatch when using jlink occurs because:
You use Liberica "Full JDK" which includes pre-built JavaFX modules in a jmod format AND
You also define JavaFX dependencies in your Maven project based on JavaFX modules in jar format.
This confuses the linker, resulting in the mismatched hash error.
The linker knows there are two copies of the same module with the same module version available on the module path, but they have different hashes, so it errors and exits.
It would be more useful if the error told you exactly where the two modules with differing hashes were found (you could create an enhancement request with the jlink tool in the JDK for that, referencing this post, if you wanted).
How to fix this
You can fix this by either:
Use a JDK distribution that does not include pre-built JavaFX modules (e.g. a standard OpenJDK download or a Liberica "Standard JDK" version) OR
Remove the JavaFX dependencies from your pom.xml file.
Getting some link debug info
To debug, in the pom.xml file configuration for the javafx-maven-plugin, add:
<jlinkVerbose>true</jlinkVerbose>
This will tell you where jlink sourced the modules from (when jlink works).
You can also run maven in debug mode (--debug command line switch for mvn). Maven will tell you a lot more information. For example, the actual full command line and option set used to invoke jlink.
Here is a debug line for linking using OpenJDK using maven jar dependencies for the JavaFX modules:
[DEBUG] Executing command line: [/Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/bin/jlink, --module-path, /Users/myusername/dev/linktest/target/classes:/Users/myusername/.m2/repository/org/openjfx/javafx-base/19/javafx-base-19-mac.jar:/Users/myusername/.m2/repository/org/openjfx/javafx-controls/19/javafx-controls-19-mac.jar:/Users/myusername/.m2/repository/org/openjfx/javafx-fxml/19/javafx-fxml-19-mac.jar:/Users/myusername/.m2/repository/org/openjfx/javafx-graphics/19/javafx-graphics-19-mac.jar, --add-modules, com.example.linktest, --output, /Users/myusername/dev/linktest/target/app, --strip-debug, --compress, 0, --no-header-files, --no-man-pages, --verbose, --launcher, app=com.example.linktest/com.example.linktest.HelloApplication]
The command line text can be useful because you can copy it and link from the command line prompt rather than from within Maven (just for testing and verification purposes).
Linking using liberica "Full JDK" which includes JavaFX jmods
For your pom.xml with these changes:
jlinkExecutable in the javafx-maven-plugin configuration set to the jlink in my liberica location.
I don't think this is necessary if the JAVA_HOME environment variable is properly configured to match the liberica distribution and the mvn tool is invoked using the liberica distribution.
jlinkVerbose in the javafx-maven-plugin configuration set to true.
all JavaFX dependencies commented out.
project module and package name changed to com.example.linktest.
I just did that because that is what I used to create the project, as long as the name is consistent everywhere, it doesn't matter what it is.
And a minimal module-info.java to generate a basic JavaFX FXML application added. The linker will output:
[INFO] --- javafx-maven-plugin:0.0.8:jlink (default-cli) # myapp ---
com.example.linktest file:///Users/myusername/dev/linktest/target/classes/
java.base file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.base.jmod
java.datatransfer file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.datatransfer.jmod
java.desktop file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.desktop.jmod
java.prefs file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.prefs.jmod
java.scripting file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.scripting.jmod
java.xml file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/java.xml.jmod
javafx.base file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/javafx.base.jmod
javafx.controls file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/javafx.controls.jmod
javafx.fxml file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/javafx.fxml.jmod
javafx.graphics file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/javafx.graphics.jmod
jdk.unsupported file:///Users/myusername/Library/Java/JavaVirtualMachines/liberica-19.0.1/jmods/jdk.unsupported.jmod
All of the JavaFX dependencies are sourced from the liberica provided jmods, such as this:
liberica-19.0.1/jmods/javafx.base.jmod
Linking using OpenJDK and JavaFX maven jars
If instead you use a standard OpenJDK without pre-built JavaFX modules and JavaFX modules added as dependencies in the pom.xml, then the output is:
[INFO] --- javafx-maven-plugin:0.0.8:jlink (default-cli) # myapp ---
com.example.linktest file:///Users/myusername/dev/linktest/target/classes/
java.base file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.base.jmod
java.datatransfer file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.datatransfer.jmod
java.desktop file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.desktop.jmod
java.prefs file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.prefs.jmod
java.scripting file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.scripting.jmod
java.xml file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/java.xml.jmod
javafx.base file:///Users/myusername/.m2/repository/org/openjfx/javafx-base/19/javafx-base-19-mac.jar
javafx.controls file:///Users/myusername/.m2/repository/org/openjfx/javafx-controls/19/javafx-controls-19-mac.jar
javafx.fxml file:///Users/myusername/.m2/repository/org/openjfx/javafx-fxml/19/javafx-fxml-19-mac.jar
javafx.graphics file:///Users/myusername/.m2/repository/org/openjfx/javafx-graphics/19/javafx-graphics-19-mac.jar
jdk.unsupported file:///Users/myusername/Library/Java/JavaVirtualMachines/openjdk-19.0.1/Contents/Home/jmods/jdk.unsupported.jmod
The javafx modules are sourced as jars out of the .m2 repository rather than coming as mods from the JDK:
.m2/repository/org/openjfx/javafx-base/19/javafx-base-19-mac.jar
Either way, you end up with a packaged, linked, usable JavaFX application.

I created a JavaFX App and I get an the following error: "JavaFX runtime components are missing, and are required to run this application" [duplicate]

I'm trying to create a JFX11 self-containing jar using maven dependencies. From the research I've done, it seems the best way to do this is through the maven shade plugin. However, When I run it, I get the this error:
Error: JavaFX runtime components are missing, and are required to run this application
I don't understand why this is happening. What am I messing up? Is there a better way to do this? I've also tried the maven assembly plugin with the same message.
pom file for reference
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>Application</groupId>
<artifactId>Main</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>SpaceRunner</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>10</release>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>Application.Main</mainClass>
</configuration>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>
Application.Main
</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>Application.Main</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
UPDATE 10/2021
Since JavaFX 16 a warning is displayed when JavaFX doesn't run on the module path, which is the case of an uber/fat jar:
$ java -jar myFatJar-1.0-SNAPSHOT.jar
Oct 02, 2021 1:45:21 PM com.sun.javafx.application.PlatformImpl startup
WARNING: Unsupported JavaFX configuration: classes were loaded from 'unnamed module #14c24f4c'
Also, you get a warning from the shade plugin itself:
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
While these warnings can be initially ignored, there is a reason for them.
As explained in this CSR:
JavaFX is built and distributed as a set of named modules, each in its own modular jar file, and the JavaFX runtime expects its classes to be loaded from a set of named javafx.* modules, and does not support loading those modules from the classpath.
And:
when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we no longer get the benefit of the java module system.
Therefore, even this widely accepted answer explains how can an uber/fat jar can be created on Maven projects, its use is discouraged, and other modern alternatives to distribute your application, like jlink, jpackage or native-image, should be used.
ORIGINAL ANSWER
This answer explains why a fat/uber jar fails on JavaFX 11. In short:
This error comes from sun.launcher.LauncherHelper in the java.base module. The reason for this is that the Main app extends Application and has a main method. If that is the case, the LauncherHelper will check for the javafx.graphics module to be present as a named module. If that module is not present, the launch is aborted.
And already proposes a fix for Gradle.
For Maven the solution is exactly the same: provide a new main class that doesn't extend from Application.
You will have new class in your application package (bad name):
// NewMain.java
public class NewMain {
public static void main(String[] args) {
Main.main(args);
}
}
And your existing Main class, as is:
//Main.java
public class Main extends Application {
#Override
public void start(Stage stage) {
...
}
public static void main(String[] args) {
launch(args);
}
}
Now you need to modify your pom and set your main class for the different plugins:
<mainClass>application.NewMain</mainClass>
Platform-specific Fat jar
Finally, with the shade plugin you are going to produce a fat jar, on your machine.
This means that, so far, your JavaFX dependencies are using a unique classifier. If for instance you are on Windows, Maven will be using internally the win classifier. This has the effect of including only the native libraries for Windows.
So you are using:
org.openjfx:javafx-controls:11
org.openjfx:javafx-controls:11:win
org.openjfx:javafx-graphics:11
org.openjfx:javafx-graphics:11:win <-- this contains the native dlls for Windows
org.openjfx:javafx-base:11
org.openjfx:javafx-base:11:win
Now, if you produce the fat jar, you will bundle all those dependencies (and those other regular third party dependencies from your project), and you will be able to run your project as:
java -jar myFatJar-1.0-SNAPSHOT.jar
While this is very nice, if you want to distribute you jar, be aware that this jar is not cross-platform, and it will work only on your platform, in this case Windows.
Cross-Platform Fat Jar
There is a solution to generate a cross-platform jar that you can distribute: include the rest of the native libraries of the other platforms.
This can be easily done, as you just need to include the graphics module dependencies for the three platforms:
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11</version>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>win</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>linux</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics </artifactId>
<version>11</version>
<classifier>mac</classifier>
</dependency>
</dependencies>
Size
There is a main issue with this approach: the size. As you can see in this other answer, if you use the WebView control, you will be bundling around 220 MB due to the WebKit native libraries.

GraalVM javafx.fxml.LoadException: Error resolving onAction='#loginAction', either the event handler is not in the Namespace

I'm running into an error running the native image produced by GraalVM (latest GraalVM built on JDK 11) via the Gluon Client Plugin.
javafx.fxml.LoadException: Error resolving onAction='#loginAction', either the event handler is not in the Namespace or there is an error in the script. fxml/LoginScreen.fxml:17
The compililation step works fine:
mvn clean client:build
I see the binary in a folder called "projectname/target/client/x86_64-linux/binaryname"
The above error produced when I run the executable via "./binaryname"
The FXML line of code which its complaining about on line 17 is:
<Button fx:id="_loginButton" layoutX="516.0" layoutY="174.0" mnemonicParsing="false" onAction="#loginAction" prefHeight="28.0" prefWidth="94.0" text="Login" />
The backing code logic are as follows and marked with #FXML:
#FXML
void loginAction(ActionEvent event) throws InterruptedException {
LoginService loginservice = new LoginService(_usernameTextField.getText(), _passwordTextField.getText());
According to a JavaFX common errors list the problem is usually because the onAction event does not have the same name as specified in the controller - Introduction to JavaFX
for Beginner Programmers - Pg 27 . However this is not the case, my program's naming is accurate. Using the JavaFX maven plugin (seperate from the GluonClient) using
maven javafx:run
the program starts up correctly and works as expected. If I need to post more information, please let me know.
Here is my pom.xml (I only replaced only the name of my package below)
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.demo</groupId>
<artifactId>com-demo-management-ui</artifactId>
<version>0.0.1-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<client.plugin.version>0.1.26</client.plugin.version>
</properties>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>11</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.openjfx/javafx-fxml -->
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-fxml</artifactId>
<version>11</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient -->
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.12</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.6</version>
</dependency>
<!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.6</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
<plugin>
<groupId>org.openjfx</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>0.0.3</version>
<configuration>
<mainClass>com.demo.Launcher</mainClass>
</configuration>
</plugin>
<plugin>
<groupId>com.gluonhq</groupId>
<artifactId>client-maven-plugin</artifactId>
<version>${client.plugin.version}</version>
<configuration>
<!-- Uncomment to run on iOS: -->
<!-- <target>ios</target> -->
<mainClass>com.demo.Launcher</mainClass>
<graalvmHome>/opt/graalvm-ce-java11-20.2.0-dev/</graalvmHome>
</configuration>
</plugin>
</plugins>
</build>
<pluginRepositories>
<pluginRepository>
<id>gluon-releases</id>
<url>http://nexus.gluonhq.com/nexus/content/repositories/releases/</url>
</pluginRepository>
</pluginRepositories>
And finally, here is the code where I set the controller (This is a method call, which I exchange my views as I need them, thus controller is passed as an argument in the creating a view):
FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource("/fxml/"+baseController.getFxmlFile()));
fxmlLoader.setController(baseController);
Parent parent = fxmlLoader.load();
Scene scene = new Scene(parent);
Stage stage = new Stage();
stage.setFullScreen(fullScreen);
stage.setMaximized(setMaximized);
stage.setScene(scene);
stage.show();
If you have a look at HelloFXML sample in the Client samples repository, you will see it uses the typical FXML file with a controller:
<AnchorPane fx:id="pane" ... fx:controller="hellofx.HelloController">
In your case, you don't have the controller in the FXML file, but you provide it like:
fxmlLoader.setController(new hellofx.HelloController());
As you know, the FXMLLoader uses reflection to instantiate controller, controls and methods that are found while parsing the FXML file.
Either way, when you click the button that triggers the loginAction method, the FXMLLoader process that with this call:
MethodHelper.invoke(method, controller, params);
that uses reflection to handle such event.
With GraalVM, reflection is an issue, and you have to "help" it a little bit, by providing the classes/methods/fields that are going to be used reflectively at some point. Find more about it here.
The Client plugin already takes care for you of adding the JavaFX core classes and methods. You can see what's added in target/client/x86_64-darwin/gvm/reflectionconfig-x86_64-darwin.json.
However, your custom classes have to be added to that file. There are two ways you can do that:
As in HelloFXML, via configuration/reflectionList, you will provide the custom class/es that will be used reflectively:
<plugin>
<groupId>com.gluonhq</groupId>
<artifactId>client-maven-plugin</artifactId>
<version>${client.plugin.version}</version>
<configuration>
<reflectionList>
<list>hellofx.HelloController</list> <!-- your custom classes -->
</reflectionList>
<mainClass>${mainClassName}</mainClass>
</configuration>
</plugin>
This has the effect of opening all class methods/fields to reflection. You will see the result in the json file as:
{
"name" : "hellofx.HelloController",
"allDeclaredConstructors" : true,
"allPublicConstructors" : true,
"allDeclaredFields" : true,
"allPublicFields" : true,
"allDeclaredMethods" : true,
"allPublicMethods" : true
}
...
This should be enough to fix your issue.
Via config files. As you can read in the Client's documentation, you can add a config file (reflectionconfig.json) to META-INF/substrate/config instead:
[
{
"name":"hellofx.HelloController",
"methods":[{"name":"loginAction","parameterTypes":["javafx.event.ActionEvent"] }]
}
]
This will fix it as well. Of course, it might require adding other methods you have in the controller too (like initialize).
This will open to reflection only this method, so it has a lower impact in memory footprint, and follows what the plugin does with the JavaFX core classes.

ERROR: Stubs could not be found. Please make sure that spring-cloud-contract:convert was invoked

Using Spring Cloud Contract 2.1.3.RELEASE with spring-boot 2.1.1.RELEASE, I have added the dependency and plugin per explained in the guide:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-verifier</artifactId>
<version>${spring-cloud-contract.version}</version>
<scope>test</scope>
</dependency>
and
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
</plugin>
I have also added under: $rootDir/src/test/resources/contracts:
Groovy file:
package contracts
import org.springframework.cloud.contract.spec.Contract
Contract.make {
name("contract_updateNodeV4")
request {
method 'PUT'
url '/v4/nodes'
headers {
header 'Content-Type': 'application/vnd.org.springframework.cloud.contract.verifier.twitter-places-analyzer.v1+json'
}
body(file("updateNodeV4_request.json"))
}
response {
status OK()
body(file("updateNodeV4_response.json"))
}
}
And corresponding updateNodeV4_request.json and updateNodeV4_response.json (omitting their contents since these are large) valid JSON files.
When running mvn clean install I expected generated tests to be created (and fail for now) per the guide.
Instead I am getting the following error:
[ERROR] Failed to execute goal org.springframework.cloud:spring-cloud-contract-maven-plugin:1.0.0.RELEASE:generateStubs (default-generateStubs) on project xxx: Stubs could not be found: [C:\Users\xxx\git\xxx\target\stubs] .
[ERROR] Please make sure that spring-cloud-contract:convert was invoked
Most likely your contacts are not under the module's src/test/resources/contracts but under the root module's folder. If that's the case you need to tell the plugin that by seeing the contracts dir plugin property
I solved it by moving the plugin:
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
</plugin>
From the root pom.xml to the specific module's pom.xml in which I have created the contracts in. Now it works as expected.

m2e-webby and provided dependencies with jetty

I have a maven project with some provided dependencies and I am trying to run the application with webby but it give me a java.lang.ClassNotFoundException exception.
In this link it says: "Webby allows to initialize a launch configuration from the configuration of the jetty-maven-plugin".
My question is it is possible to also pass the dependencies defined in the jetty-maven-plugin? If not how can webby resolve the provided dependencies?
Want I did was to create a profile in the pom project:
<profile>
<id>webby</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
</dependency>
</dependencies>
</profile>
And then right click on the project -> properties -> Maven and added webby to the Active Maven Profiles

Resources