I have an Eclipse RCP application which I need to launch from Windows Run dialog.
I tried it by setting a key in REGISTERY entry in
HKLM\SOFTWARES\Microsoft\Windows\Current Version\All Paths\**full path to exe**
but the app was not launching. How can I launch an RCP application from the RUN dialog?
File hierarchy in the folder:
Entry in registry(app name Hello.exe:
The exe is not loading because in the .ini file endorsed folder is specified to take from the current location (./endorsed). How can I tell the machine to load jars from an endorsed folder?
One approach I found to be working is that to modify the .ini file at run time, so we can specify the full path for the endorsed folder while run time. But is that a good design?
Dont use registry entries. Rather specify the full path.
Related
This is an educational Java/Swing app (JDK 16.0.2) which I'm trying to manufacture for MacOS distribution.
I'm using jpackage (jdk-16) to build the installer/launcher. Learning the Terminal/Xcode command line interface has been....interesting.
When I test the installer on the sw mfg. host intel-iMac, it launches correctly, including showing the app's splashscreen and icon set.
But, when I run the same installer on a different intel-iMac then launch, the launcher can't find the main class: (bug replicated on a MacBook Pro)
Excerpt from launcher TerminalExec session:
Error: Could not find or load main class workspace2D.DataflowGeometry2D
Caused by: java.lang.ClassNotFoundException: workspace2D.DataflowGeometry2D
What could cause the launcher to fail to find main() except on the mfg. host iMac?
The installed .cfg file has:
app.mainclass=workspace2D/DataflowGeometry2D
which is the correct reference satisfying the launcher in the first test case.
I finally figured this out. The "jpackage" documentation is weak as far as the necessary preconditions in your file structure for your Java project. All the examples they show are "toy" projects ("HelloWorld")
thus avoiding how a typical app-project as structured.
My mistake was creating my MacOS_Manufacturing folder (a target location for the .jar and for the installer .dmg) OUTSIDE the Project folder.
The --input parameter to jpackage names a folder on the sw mfg. computer whose entire contents will be copied onto the installed computer --> MyApp.app/Contents/app folder. I was naming the Project/bin folder as the "--input", which was copying all the .class files and datafiles -- but NOT the .jar. What threw me off is that my DataflowGeometry2D.class files was sitting right there on the installed computer, and yet the launcher couldn't find it???
The launcher is looking for main-class INSIDE the jar, not as a standalone .class file.
I moved the target location for the .jar on the sw mfg. computer to be inside the Project/bin folder. That guarantees it is copied onto the installed computer during the install.
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 work on an existing Maven project with Eclipse Luna and WebSphere 8.5.5.1.
The source of the ibm-application-bnd.xml is:
D:\projects\svn\application\ear\src\main\application\META-INF\ibm-application-bnd.xml
Once a day, at a random moment, the application folder itself is overwritten with the ear-file, so the \main folder contains a binary file named application and is actually the ear file because I openend the file because I saw it had the same size as the ear (8 MB).:
D:\projects\svn\application\ear\src\main\application
The happens at least once a day, and I have the impression that Eclipse, or JRebel of WebSphere creates this file.
The result is that I have to quit Eclipse, delete the file and update from SVN to get the application folder with the binding xml back.
Any thought how to fix this?
Easy way you could stop the folder from being deleted (and perhaps also find the culprit) is to open command prompt in that directory - it won't allow the folder to be removed in that case.
I have created a Java Web Start Application. So my application launch from the web browser. I need to run an executable file on MAC OS. So I have packaged my executable file inside my jar file. But I am not able to load it from the classpath as it gives me File or Directory does not exists exception. Then I have tried by extracting the jar file, but as it is launched from the web browser, I am not able to get the location of the jar file. I have seen the path of java cache from the Java Control Panel, and I have searched on that path but not getting anything.
Is there any option to use the executable which resides in jar file without extracting jar file ?
How do I get my downloaded jar file in the system ? I have checked the java control panel path but I am not getting the jar file.
I want to copy the executable to temp directory. How do I ?
Please help me on this.
I'm unable to use "Jar Bundler" on mac to create JMeter.app from ApacheJMeter.jar, I was wondering if anyone else had previous experience with configuring this tool? The problem for me seems to be that the lib folder being searched is set to an incorrect base path:
org.apache.jmeter.NewDriver: JMeter home directory was detected as: /Users/username/Applications/JMeter.app/Contents/Resources
I looked here: http://developer.apple.com/library/mac/#documentation/Java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html
But no matter how I configured any of the said properties, the logs looked the same.
The real trick is making sure the bin and lib folders can be found. The only jar file you will need to add is ApacheJMeter.jar. Look in the bin/jmeter script for additional properties to put into the properties tab of the Jar Bundler. The java arguments in the bin/jmeter script should be copied into the VM Options field. Check Set Working Directory to Inside Application Package. Now create application. Open up the .app folder that was just created and copy the bin and lib folders into the Resources directory. Done.