Open ekis opened 8 years ago
My investigations on this continue, here is the summary of current efforts.
sbt-native-packager
. I didn't know exactly to what this referred so I had assumed I should be trying the batch script that can be found in %APPDIR%\app\bin
. Observations:
The system cannot find the file c:\Program Files\bootstrapCli\app\bin\\\..\BOOTSTRAPCLI_config.txt.
A Java JDK is not installed or can't be found.
bootstrapCli.cfg
in %APPDIR%\app\bin
directory, so I changed line 21 in batch file to point to correct file. The error did disappear but this seems like a bug, though I don't know if it's sbt-native-packager
or invoked jdkpackager
responsibility to create the batch file; I assume the former? If that is the case, should we log a bug or at least update the docs?runtime
application directory but it seems this directory contains a certain subset of JDK files, probably the bare minimum needed for generated entry point .exe
file to use the Invocation API, get the jvm.dll
and fire up the JVM. The generated .exe
file then uses the generated bootstrapCli.cfg
file to pass various options to JVM. However, if that is the case, then what is the purpose of the batch file I had invoked? The batch file seems to rely on JDK being installed which is contradictory to the idea of bundled application - so this is quite confusing and unexpected.bootstrapCli.cfg
and then running the generated .exe
file. Observations:
app.mainjar
property value to point to a "non-launcher" bootstrap JAR. It now essentially throws ClassNotFoundException
on defined main class which is relatively expected as the JAR's manifest file contains no Class-Path
element.
Class-Path
element using the boostrap launcher JAR. Ineffectively, as it throws the familiar Error invoking method
dialog (same as running the launcher JAR) followed by Failed to launch JVM
.lib\
to every JAR specified in generated bootstrapCli.cfg
. That also prevented the ClassNotFoundException
but was ultimately ineffective as it threw the Error invoking method
dialog after path manipulation.After this it became clear it is inadvisable to touch the generated .cfg
file so I reverted everything to stock and just wanted to see if the JVM is actually loaded. As it turns out, it is - using ProcExp and ProcMon I was able to prove the jvm.dll
is successfully found and loaded. So why is JVM failing to launch is still a mystery I don't know how to investigate any more.
Additional question is - what is the actual purpose of app.classpath
property value in generated .cfg
? I observed this file is being read by generated .exe
but why do we include the full classpath? It is already included in launcher JAR's manifest. Does the JVM care? It does but only if passed a single class - since we're always(?) passing in JAR files, the classpath should be read from the JAR file (MANIFEST.MF).
Summary: the problem is still unsolved but the whole process is very opaque and hard to reason about. We should improve the documentation to be a little bit more specific about the components and process involved - such as it is, the debugging process amounts to box rattling and observing the effects. Can we do better?
@ekis Are you using sbt-assembly
?
@metasim No, I am not - perhaps I was unclear: I had never used it not together with sbt-native-packager
just had the definition in plugins.sbt
. I had removed sbt-assembly
altogether (together with definition) but that didn't help.
@ekis Does sbt-dependency-tree
or the Ivy reports indicate any evictions?
@ekis Thanks for the rich explanation. So in summary the generated exe is corrupted in many ways. So we have to find out who is responsible for corrupting the exe. I have no experience with windows packaging so this is just a few more hints to follow
.cfg
jdkpackager
then you are essentially building with the java8 packager tool, you could try this standalone with a working example of your appJavaAppPackaging
and use the windows:packageBin
and see if this works. Also this won't include a JRE@ekis To echo off of @muuki88's comments, if you're able to manually edit the generated build.xml
file and use Ant directly to get things to work, and let us know what you had to change, it would help us see if there's some check missing in the plugin.
I'm also not sure what this .cfg
file is... maybe something generated by javapackager
on windows? At any rate, the build.xml
file is the authoritative definition from the plugin's standpoint. Anything downstream from that is javapackager
land.
I am trying to build an executable, bundled JAR with JDK Packager plugin on Windows and Inno Setup - and while the packager plugin itself produces an installable resource and I cannot see any errors during the packaging, after installation I am left with an unusable application and little hints as to what is going on and why.
I have the full synopsis of the problem here but in a nutshell, the packaged exe throws some hard-to-reason about errors and there is no error log whatsoever (at least I cannot find any). I've been bashing my head with this for two days and cannot figure out what is going on - I've tried to go the Wix way but that seems even crazier: I could not get even the
My First Packaged Tutorial
to build correctly.Can we do anything on
sbt-native-packager
side to make these (as detailed on SO link) errors a little bit more explicit or is it all out of our hands?Lastly, I understand this may not be the best place to post such issues but I would really appreciate if someone could take a look at the issue and/or provide some hints where to go next as this lack of sensible logging is frustrating. I've went through JDK Packager documentation, all tutorials on
sbt-native-packager
, Oracle JavaPackager docs (such as they are) and ant javafx reference - but am no closer to understanding what is going on, why is this happening and what have I done wrong.If there is anything I can post to help move this forward, please don't hesitate to ask.