Package custom Flyway release in Quarkus - flyway

The current Quarkus 1.0 release uses Flyway 6, whose CE is not supporting some older database versions.
I tried to exchange in the pom file the default Flyway version of the quarkus-flyway artifact with an older Flyway release, but Quarkus then crashes on startup with some flyway-fluent...-method-not-found exception.
Would there be some easy way to accomplish switching Flyway releases?

Due the build time nature of a lot of Quarkus extensions, changing the version of the dependency may or may not work.

If you use maven, you can custom flyway verions in pom.xml, like this:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-flyway</artifactId>
<!-- exclude flyway-core -->
<exclusions>
<exclusion>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>'custom version you want'</version>
</dependency>

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.

Unable to start server when I use Eureka and actuator

I am using Spring boot version 2.2.0.M4. When I am adding dependencies
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>2.1.2.RELEASE</version>
</dependency>
while starting server it fails to start with below mentioned error
APPLICATION FAILED TO START
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.cloud.client.discovery.health.DiscoveryCompositeHealthIndicator.<init>(DiscoveryCompositeHealthIndicator.java:42)
The correct way of working with Spring Cloud projects versioning is using the dependencyManagement plugin and release trains versions rather than passing versions of separate artifacts manually.
You can get a correct pom generated automatically (with all the correct versions) at start.spring.io.
On the date that question was posted, a version of Spring Cloud supporting Spring Boot 2.2.x has not been released yet. The latest Spring Cloud release version available is Greenwich.SR2, that supports Spring Boot 2.1.6.RELEASE.
UPDATE: Spring Cloud Hoxton.M1 that supports Spring Boot 2.2.0.M4 was released on 3rd July 2019. You can now use it and also generate correct build files with this version from start.spring.io.
For the following dependency:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.4.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
The Following spring cloud version worked for me.
<properties>
<java.version>11</java.version>
<spring-cloud.version>Hoxton.SR4</spring-cloud.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

WARNING: you seem to not be using the Xerial SQLite driver

I used libs
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.8.6</version>
</dependency>
<dependency>
<groupId>com.j256.ormlite</groupId>
<artifactId>ormlite-core</artifactId>
<version>4.48</version>
</dependency>
<dependency>
<groupId>com.j256.ormlite</groupId>
<artifactId>ormlite-jdbc</artifactId>
<version>4.48</version>
</dependency>
Run a main class shows too many errors:
WARNING: you seem to not be using the Xerial SQLite driver
How to disable it
help me
You can use an older version of sqlite-jdbc to avoid this incompatibility:
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.7.2</version>
</dependency>
Or just add the dependency which got removed in 3.8 versions, therefore causing error:
<dependency>
<groupId>org.xerial</groupId>
<artifactId>sqlite-jdbc</artifactId>
<version>3.8.10.1</version>
</dependency>
<dependency>
<groupId>org.xerial.thirdparty</groupId>
<artifactId>nestedvm</artifactId>
<version>1.0</version>
</dependency>
OrmLite checks for existence of org.ibex.nestedvm.Interpreter class, which is not present in newer versions of Xerial driver. But you can simply create that class in your project, just empty class with no members to suppress the warning.
UPD: Check was removed though not released yet.

Magnolia could not be started java.lang.NoClassDefFoundError

I am running an magnolia Application using magnolia-blossom.
I have added this dependency jar below :
<dependency>
<groupId>info.magnolia</groupId>
<artifactId>magnolia-module-standard-templating-kit</artifactId>
<version>2.7</version>
<type>jar</type>
</dependency>
I am getting the error :
Oops, Magnolia could not be started java.lang.NoClassDefFoundError:info/magnolia/dam/provider/AssetProviderNotFoundException
for which Tomcat server is unable to start.
Can anyone suggest me that how can i resolve this Error.
You're missing Magnolia DAM, use this dependency snippet:
<dependency>
<groupId>info.magnolia.dam</groupId>
<artifactId>magnolia-dam</artifactId>
<version>1.2</version>
</dependency>
I found the version used by STK 2.7 by looking at its POM here https://nexus.magnolia-cms.com/content/repositories/magnolia.public.releases/info/magnolia/standard-templating-kit-parent/2.7/standard-templating-kit-parent-2.7.pom

HttpServletRequest getPart(") not found

I don't know why it is not working.
I am trying to accept multipart-formdata in my servlet but request.getPart("") is not showing. I am using glassfish 3.1.2 server. Tha framework used is vaadin for developing application. Can any one help me to fix this problem?
Assuming that your concrete problem is indeed that your IDE didn't show the getPart() method on autocomplete, then that can only mean that the project is not configured as a Servlet 3.0 compatible project. That method was namely introduced in Servlet 3.0.
You didn't tell anything about which IDE exactly you're using and your question history doesn't give any clues as well, so let's assume that it's Eclipse which is rather widely used. In that case, you need to configure it at 2 places, provided that you've correctly associated the Dynamic Web Project with a Servlet 3.0 compatible container as Targeted Runtimes in project's properties (otherwise HttpServletRequest and consorts wouldn't have compiled at all):
In the Project Facets section of project's properties, the Dynamic Web Module version must be set to 3.0.
If your IDE has generated a /WEB-INF/web.xml file, then you need to make sure that its <web-app> root declaration also matches Servlet 3.0, otherwise it would still fail during runtime.
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
</web-app>
I had the same problem. Here's what eventually turned out to be the problem for me. I had a dependency on:
<dependency>
<groupId>com.googlecode.jsontoken</groupId>
<artifactId>jsontoken</artifactId>
<version>1.1</version>
</dependency>
And it turned out jsontoken has a dependency on servlet-api 2.5. So what fixed the problem was simply this:
<dependency>
<groupId>com.googlecode.jsontoken</groupId>
<artifactId>jsontoken</artifactId>
<version>1.1</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
This worked for me
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
To those that stumble on this later, if the resolution suggested by BalusC does not resolve the problem for you please check your build path for provided libraries whose runtime does not match the runtime of your server.
For example if your maven pom.xml contains entries that provide java EE libraries like so...
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>javaee-api</artifactId>
<version>5.0-1</version>
<scope>provided</scope>
</dependency>
... they can interfere with what your IDE perceives as the runtime environment, which will be used to provide code completion suggestions.
The easiest way to track the problem is to figure out where the HttpServletRequest class is sourced from.
maven.. pom.xml.. modify this dependency
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
</dependency>
servlet api 2.5 is not work
I had the same problem, I want to share it with you in case anyone else bumps in the same problem:
In my case I had a j2ee.jar which was automatically downloaded and its version was probably old. It was located under Libraries --> j2ee Runtime Library (stackoverflow doesn't let me add an image so in eclipse - in Project Explorer - expand the project --> Java Resources --> libraries --> J2ee Runtime Library --> j2ee.jar)
I went to the file system where this file was located (you have the location next to the file in eclipse) and replaced it with a newer jar. You can take the jar from here.
Then clean and rebuild the project.
One possible reason, as pointed out in Bjørn's answer, is a conflicting artifact servlet-api (Servlet 2.5 spec).
In my case it was this dependency
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client-appengine</artifactId>
<version>1.30.10</version>
To find out which dependency compiles the conflicting library just build and print the dependency tree with:
mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree -Dverbose=true
Part of the output:
Finally exclude the artifact from the dependency
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client-appengine</artifactId>
<version>1.30.10</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Hi friends I too faced simillar problem and I will tell you what I did.
I'm using eclipse juno and Tomcat 7 server. Make sure you use latest servlet API jar. Tomcat 7 will only support dynamic module version 2.5 not more than that. So use higher Tomcat version or lower dynamic module version then it will work.
One more thing: open your servlet api jar and see whether it contains "Part" you can easily check it.

Resources