gradle-launch4j | A gradle-plugin to create windows executables with launch4j | Plugin library
kandi X-RAY | gradle-launch4j Summary
kandi X-RAY | gradle-launch4j Summary
The gradle-launch4j plugin uses launch4j 3.14 to create windows .exe files for java applications. This plugin is compatible with the Gradle versions 2 and later. Since version 2.5 this plugin requires *Java 8, as launch4j in version 3.14 requires that as well. If you are still forced to work with Java 6, use the latest version 2.4.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of gradle-launch4j
gradle-launch4j Key Features
gradle-launch4j Examples and Code Snippets
Community Discussions
Trending Discussions on gradle-launch4j
QUESTION
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:
...ANSWER
Answered 2019-Dec-06 at 07:20Your 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
QUESTION
According to this oracle docs there is a conventional java app packaging along with runtime JRE. (Self-Contained Application Packaging)
I know that there is this thing (Launch4j gradle plugin) but I'd prefer to have a bat/sh executables along in the package.
Going through gradle docs and googling I can not seem to find is there is a way to teach gradle to package desktop app with JRE. Is there?
...ANSWER
Answered 2017-Nov-05 at 13:37Have you tried this plugin yet?
QUESTION
Please note: Although I specifically mention two Gradle plugins here, this is 100% a question about understanding task dependencies in Gradle, and does not require any knowledge of the individual plugins (I think)!
I have a project that will use two Gradle plugins:
- The Gradle Shadow plugin, which will produce a self-contained "fat jar" (basically a large jar with all my classes plus the classes of all my transitive dependencies, which then allows me to just run
java -jar myapp.jar
without having to manage the jar's external classpath, etc.). This will produce a fat jar atbuild/libs/myapp.jar
; and - The Gradle Launch4J plugin, which uses Launch4J under the hood to convert a jar into a native executable (EXE, etc.). Obviously the fat jar has to be created prior to the Launch4J tasks run, otherwise they'll have nothing to wrap inside of an EXE!
Here's my build.gradle
:
ANSWER
Answered 2017-Mar-15 at 10:18Once you write
createAllExecutables.dependsOn shadowJar
you'll define the dependency between createAllExecutables task and shadowJar, which means every time Gradle decide to invoke createAllExecutables
(e.g. because you pass that to the command line, or other task will depend on it) shadowJar
will also be added to the task graph. So in that case when you invoke gradle createAllExecutables
the shadowJar
will be also executed.
But you can also write
createAllExecutables.mustRunAfter shadowJar
In that case, you won't introduce any dependency relation between tasks, but you will instrument Gradle about anticipated order for those two tasks. In that case, once you invoke gradle createAllExecutables
the shadowJar
won't be executed.
I think the dependsOn
relation is more applicable in your case, since in order to create executables you need to have fat jar already, so it's a depend on relation, not must run after.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install gradle-launch4j
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page