I'm having some troubles trying to deploy a JavaFX application. In order to simplify my problem I've tried to do the same with a "Hello word" application and the problem is the same.
I'm currently using IntelliJ IDEA and Gradle.
My build.gradle file is this:
apply plugin: 'java'
apply from: "http://dl.bintray.com/content/shemnon/javafx-gradle/8.1.1/javafx.plugin"
repositories {
mavenCentral()
}
javafx {
mainClass 'Main'
}
That build.gradle file works. The problem is that it embeds the JRE into the bundle so the file size is about 175 MB. That's too much for a simple "Hello World" app, don't you think?
So, I want to bundle this simple app without the JRE (yes, I know that I should distribute my app with the JRE bundled so it doesn't relay on uses system but I'm going to distribute both versions: with and without JRE bundled). In order to do this I add a single line to the build.gradle file (as explained in this link:
...
javafx {
mainClass 'Main'
javaRuntime '<NO RUNTIME>'
}
But no bundles are generated when gradle jfxDeploy. In fact, running gradle jfxDeploy -i show some interesting info:
Java runtime to be bundled: none, bundle will rely on locally installed runtimes
...
Skipping Mac Application Image because of configuration error The file for the Runtime/JRE directory does not exist.
Advice to Fix: Point the runtime parameter to a directory that containes the JRE.
Skipping DMG Installer because of configuration error The file for the Runtime/JRE directory does not exist.
Advice to Fix: Point the runtime parameter to a directory that containes the JRE.
Skipping PKG Installer because of configuration error The file for the Runtime/JRE directory does not exist.
Advice to Fix: Point the runtime parameter to a directory that containes the JRE.
Skipping Mac App Store Ready Bundler because of configuration error The file for the Runtime/JRE directory does not exist.
Advice to Fix: Point the runtime parameter to a directory that containes the JRE.
Ok, so maybe the plugin has some bugs. I try to generate the bundle with javapackager. I go to project folder and run the following:
javapackager -deploy -native image -srcfiles build/libs/ -outdir build/distributions -outfile Sample -appclass Main
The output is OK. The bundle is correctly generated with the JRE embedded. Now I try to generate a bundle without the JRE with this:
javapackager -deploy -native image -srcfiles build/libs/ -outdir build/distributions -outfile Sample -appclass Main -Bruntime=
(It's the same command appending -Bruntime= as explained in this link).
The bundle is generated. Now its size is about 500 KB. But when I try to run it nothing happens. Running it in a terminal gives the following (simplified) output:
$ Main.app/Contents/MacOS/Main
Failed to find library.:
Main:Failed to locate JNI_CreateJavaVM
Main:Failed to launch JVM
It seems that the bundle is not capable to start the local JVM. The jar is correctly generated and added to the bundle. Running it with java -jar runs the app but I don't know why it doesn't work when running the bundle
FYI, I'm running java 1.8.0_74, javac 1.8.0_74 and javapackager 8.0 in an OS X 10.11.2
The javafx.plugin from shemnon isn't developed nor maintained anymore, for that reason I've created the javafx-gradle-plugin.
The problem comes with the internal changes of the .cfg-file-format, they use INI-files now, but that is flawed in term of RUNTIME-configuration.
Official JDK-bug-tickets reported by me:
(jdk 9) https://bugs.openjdk.java.net/browse/JDK-8143314
(jdk 8) https://bugs.openjdk.java.net/browse/JDK-8143934
It should be enough to set some bundler-argument launcher-cfg-format to cfg within your build (or use the javafx-gradle-plugin, which includes that workaround automatically).
Disclaimer: I'm the maintainer of the javafx-maven-plugin and the creator and maintainer of the javafx-gradle-plugin.
UPDATE this got fixed and made available with JDK 8u92
Related
I have a really simple java spring-boot gradle application.
When I build an image from source with:
pack build testapp:0.0.1 --builder paketobuildpacks/builder:base
and try to run it with docker I get the following error:
ERROR: failed to launch: determine start command: when there is no default process a command is required.
The generated Entrypoint in this image is "/cnb/lifecycle/launcher".
When I inspect the image with pack inspect-image there are no processes.
I tried this with different java spring-boot gradle applications. When I use the "bootBuildImage" gradle task, it does nearly the same but uses the pre-build .jar-file and the resulting image works. The generated Entrypoint in this image is "/cnb/process/web" and pack inspect-image shows three processes.
Any ideas?
I can't see your build output, but it sounds like you're hitting a known issue. If this is not your problem, please include the full output of running pack build.
Onto the issue. By default, Spring Boot Gradle projects will build both an executable and non-executable JAR. Because this produces two JAR files, it presently confuses the buildpacks.
There are a couple of solutions:
Tell Gradle to not build the non-executable JAR. The buildpack requires the executable JAR. You can do this by adding the following to your build.gradle file:
jar {
enabled = false
}
This is the solution we have used in the Paketo buildpack samples.
If you don't want to make the change suggested in #1, then you can add the following argument to pack build: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/<your-jar>.jar. For ex: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/demo-0.0.1-SNAPSHOT.jar. You can use glob-style pattern matching here, but you need to make sure that what you enter does not match *-plain.jar. That will be the non-executable JAR that gets built by default.
This option just simply tells the Gradle buildpack more specifically what the JAR file to pass along to subsequent buildpacks.
We also have an open issue that should help to mitigate this problem. When the executable-jar buildpack gains support for multiple JARs, it'll be less likely that you'll need to set this. Essentially, this fill will add support so the executable-jar buildpack can inspect and detect an executable JAR, which would allow it to throw out the -plain.jar file since it's not executable.
Please note: I have created this GitHub project right here that can be used to perfectly reproduce the problem I'm seeing.
Java 8 here attempting to use Launch4J via the gradle-launch4j Gradle plugin to build a Windows native EXE application. I am doing the development of a Java Swing app on my Mac but the app must run as a Windows EXE on Windows 10. I am also using ShadowJar to build my self-contained "fat jar".
I can build my (Swing) app's fat jar and then run it on my Mac via java -jar build/lib/myapp.jar. It starts and runs no problem.
Here is my Gradle config for Launch4J:
launch4j {
mainClassName = 'com.example.windows.hello.HelloWindowsApp'
icon = "${projectDir}/icon.ico"
jdkPreference = 'jdkOnly'
initialHeapSize = 128
jreMinVersion = '1.8.0'
jreMaxVersion = '1.8.9'
maxHeapSize = 512
stayAlive = false
bundledJre64Bit = true
bundledJrePath = '../hello-windows/jre8'
}
When I run ./gradle clean build shadowJar createExe createDistro it produces:
hello-windows.zip/
hello-windows.exe --> The Windows EXE built by the 'createExe' task
lib/* --> The lib/ dir for the EXE that is also built by the `createExe` task
jre8/ --> OpenJDK JRE8 (copied from the libs/jre8 dir)
So I copy that ZIP file and port it over to a Windows 10 (64-bit) machine. I extract the ZIP and run the EXE by double clicking it inside Windows Explorer (which I can confirm does see the EXE as an Application type). First I see this:
Why is this happening? Are there any Launch4J configurations/settings I can change so that this doesn't happen?
Thanks in advance!
You need to sign the executable created by launch4j as described here to prevent SmartScreen from blocking it to be run. See also the related discussion in the support forum.
Your first question is more like a Windows question. When you unzip an application from a zip file, Windows will naturally mark it as unsafe, in fact if you check the application properties tab, you will see a checkbox where you can remove that unsafe attribute. It's same as running chmod+x for an executable script in Linux.
For the second part, I assume you are using the gradle plugin for Launch4j, there are two main ways to configure Launch4j assuming your project folder is structured commonly with the jre library in the same folder containing your executable folder.
By specifying the path only like
../jre
By specifying the full relative path
../jre/bin/javaw.exe
Your generated xml at the end should look like this in the first case.
<jre>
<path>../jre</path>
</jre>
The main point is that the path to JRE is relative to the position of the executable not the current directory. In this case, we step back one directory from the executable folder to the folder containing jre.
Try setting the bundledJrePath in your build.gradle to just jre8:
launch4j {
...
bundledJrePath = 'jre8'
}
Because that is in your case the relative path where the jre is when extracting the zip.
http://launch4j.sourceforge.net/docs.html
<path>, <minVersion>, <maxVersion>
The <path> property is used to specify the absolute or relative path (to the executable) of a bundled JRE, it does not rely on the current directory or <chdir>. Note that this path is not checked until the actual application execution
Beware that the path must not contain the /bin/javaw.exe.
When running the exe with the debug flag like this
hello-windows.exe --l4j-debug
then it will create a file launch4j.log in the same directory.
There you can check that the correct jre is picked up, for example:
...
Bundled JRE: jre8
Check launcher: C:\Users\IEUser\Downloads\hello-windows\jre8\bin\javaw.exe (OK)
...
I upvoted the answer above from sschuberth, as that is the best answer to your question. Signing the executable will make SmartScreen happy.
As addition I would rather prevent trying to create an executable, even signing it, best to create a MSI. For example by using Javapackager. See also this question. That guy created his own tool after using Nullsoft.
It is very cumbersome to get an executable accepted by every virus scanner around the world. I have the experience of using WIX Toolset to create an MSI and wrapped it into a bootstrapper executable, signed it using the company signing certificate. However in the end I had to send requests to McAfee, Norton, Avast, AVG, KasperSky and Trend Micro. Gladly all accepted it over time, only Trend Micro never even responded.
I follow the instructions in https://spring.io/guides/gs/spring-boot/#scratch, but when it says to run:
./gradlew build && java -jar build/libs/gs-spring-boot-0.1.0.jar
the build fails with the above error.
There is message before the failure that says:
Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
See https://docs.gradle.org/4.8.1/userguide/command_line_interface.html#sec:command_line_warnings
but everyone online says that's just a warning.
The build doesn't appear to create or download build/libs/gs-spring-boot-0.1.0.jar.
Currently completely blocked on first attempt to use Gradle.
I just had this problem.
The tutorial is in error in what you need to run. It should be
$ gradlew build && java -jar build/libs/gs-rest-service-0.1.0.jar
I think that they updated the code, but forgot to update the tutorial.
I had the same issue when build a simple project with Maven on Intellij IDEA. (Ubuntu 18.04.2).
Just typed terminal (in project directory):
$ sudo mvn package
$ java -jar ./target/(your-project-name)-(<version> at pom.xml).jar
For example my project name is hello-world-spring and version name in pom.xml is <version>0.0.1-SNAPSHOT</version>, I have to type:
$ sudo mvn package
$ java -jar ./target/hello-world-spring-0.0.1-SNAPSHOT.jar
Maybe this method can work for gradle as well.
Please check the path of the jar file build/libs/gs-spring-boot-0.1.0.jar. For your case, the jar might be in a different folder. If your code is in a module in the main project, then the jar will be in the build folder of the module.
If you git clone the repo, then the tutorial works. If you "To start from scratch, move on to Build with Gradle.", then the tutorial doesn't work. There are missing setup steps.
I got the same issue and I changed the command to java -jar target/rest-service-0.0.1-SNAPSHOT.jar (I checked the .jar file in target folder and found that the file name was incorrect).
Parent folder of my project was having spaces in it's name, i changed it to the underscore and it worked.
Looked at the command line as it was in the official guide:
./gradlew clean build && java -jar build/libs/gs-actuator-service-0.1.0.jar
First, the above command line has two parts:
(1) ./gradlew clean build //Use gradle wrapper to build
(2) java -jar build/libs/gs-actuator-service-0.1.0.jar //To run an application packaged as a JAR file
Now, one might run into issues with one part or both parts. Separating them and running just on thing at a time helped troubleshoot.
(1) didn't work for my Windows, I did the following instead and that built the application successfully.
.\gradlew.bat clean build
Now moving to (2) java -jar build/libs/gs-actuator-service-0.1.0.jar
It literally means that "Run a jar file that is called gs-actuator-service-0.1.0.jar under this directory/path: build/libs/" Again, for Windows, this translates to build\libs\ , and there's one more thing that may catch you: The jar file name can be slightly different depending on how it was actually named by the configuration in initial/setting.gradle:
rootProject.name = 'actuator-service'
Note that the official guide changed it from 'gs-actuator-service' to 'actuator-service' in their sample code but hasn't updated the tutorial accordingly. But now you know where the jar file name comes from, that doesn't matter anymore, and you have the choice to rename it however you want.
Having all the factors adjusted, below is what eventually worked in my case:
java -jar build\libs\actuator-service-0.0.1-SNAPSHOT.jar
or
java -jar C:\MyWorkspace\Spring\gs-actuator-service\initial\build\libs\actuator-service-0.0.1-SNAPSHOT.jar //with fully qualified path
If you are curious where does "-0.0.1-SNAPSHOT" come from, here it is:
in build.gradle
version = '0.0.1-SNAPSHOT'
Again, you have the choice to modify it however you want. For example, if I changed it to 0.0.2-SNAPSHOT, the command line should be adjusted accordingly
java -jar build\libs\actuator-service-0.0.2-SNAPSHOT.jar
Reference: https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html
Because you are trying to execute .jar file that doesn't exist. After building the project go to ./build/libs and check the name of freshly built .jar file and then in your project directory run:
./gradlew build && java -jar build/libs/name-of-your-jar-file.jar
or you can set version property to empty string in your build.gradle file
version = ''
after that:
./gradlew build && java -jar build/libs/your-project-name.jar
For Windows, these commands solved the problem: "Error: Unable to access jarfile springboot.jar":
cd target
java -jar springboot-0.0.1-SNAPSHOT.jar
run ./mvnw package
Now a folder named target is created and you can see a jar file inside it.
then execute java -jar target/<jarfilename>
Intellij is giving me errors all around for brand new kotlin/spring project and I cannot build or run the project from the IDE.
If I do it from the command line however, there are no issues and I can build and run the app.
'classpath' in 'org.gradle.api.artifacts.dsl.DependencyHandler' cannot be applied to '(groovy.lang.GString)'
'apply' in 'org.gradle.api.plugins.PluginAware' cannot be applied to '(['plugin':java.lang.String])'
Cannot access class 'java.lang.String'. Check your module classpath for missing or conflicting dependencie
Type mismatch.
Required:
java.lang.String
Found:
kotlin.String
Any ideas to what may be the issue?
I tried Kotlin multiplatform JVM type mismatch in InteliJ but doesn't seem to fix the issue.
UPDATE:
Cleared gradle caches, reinstalled Intellij, Import project that was created from start.spring.io with Gradle and Kotlin selected.
Using default gradle wrapper and project jdk (the path says jre)? gives me an error. Open gradle settings just opens the file explorer.
Using default gradle wrapper and machine local JDK same issues with the dependencies from above.
This issue comes up if you set up your own module inside IntelliJ and you think that since you are doing a Kotlin (Maven) project, the SDK should be set to Kotlin. Wrong!
The problem is shown in the first image. The project SDK is set to Kotlin.
Change it to Java. Probably any 8+ Java will be good enough.
This solves the IDE errors and the compiler errors as well.
Unset KOTLIN_HOME and other Kotlin- or Java-related settings you may have in your environment (env to check, unset NAME to unset.)
Then kill any Gradle daemon still running (pkill -f GradleDaemon) and test your Gradle build from the terminal. If all goes well, remove the .idea directory; restart IDEA, making sure to run it without the stray environment variables (for example, launch idea.sh from the terminal where you unset them); and re-import your project, with the choice of using the default Gradle wrapper.
If you need to use standalone Kotlin versions, installed for example through SDKMAN, consider taking the SDKMAN activation lines out of your shell init file (.bashrc for Bash) and into a standalone script (say, ~/bin/sdkman) that will also change your shell prompt (PS1 in Bash) to remind you that you have entered a SDKMAN-managed CLI session.
Congratulations on the spring state machine, I found it yesterday and have been trying it out, specifically the turnstile example running in STS. I found it very easy and intuitive to build a FSM.
Because spring shell doesn't work well in STS I tracked down the instructions to run the examples from the command line in the reference doc,
"java -jar
spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar"
,
but running it got an error
"no main manifest attribute, in spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar".
Although not even a novice in using gradle, I tried fixing this by adding this line to build.gradle in the jar section
"manifest.attributes['Main-Class'] = 'demo.turnstile.Application'"
(which doesn't handle the various sub-projects I know) but got this error
"NoClassDefFoundError: org/springframework/shell/Bootstrap".
If it is possible to run the samples from gradle, could you include them in the reference document? I tried running the samples using
gradle run
but it there was no interaction with the shell scripts.
Samples are designed to be run as executable jar and with shell so that you can interact without a need to recompile with every change. Your error indicates that you didn't build that sample jar as mentioned in docs.
./gradlew clean build -x test
This will automatically use spring boot plugin which will add the necessary jar manifest headers to jar meta info to make it a true executable jar. Essentially every every sample is a spring boot app.
Building SM sample projects in Windows Environment:
Open Command prompt (windows key + r -->cmd-->Enter), Change directory to project root folder spring-statemachine-master (Inside the Extracted folder).
Run gradlew install to get all spring dependencies copied to local machine.
Run gradlew clean build -x test to get the spring shell jars built. Courtesy Janne
These steps should ideally get all .jar built, look into \build\libs folder of respective sample project for jar files.
Run the like any other java jar file java -jar [jar-file-name.jar] (make sure to be change directory to jar file directory location).
One more thing where I was stuck was, How to give events to SM:
It's like this sm event EVENT_NAME_AS_DEFINED_IN_CLASS. Ref
E.g.: sm event RINSE --> to washer project