GRIP
GRIP copied to clipboard
Building native .deb app is broken
Caused by #757. Reverting the merge commit (f7efad2d408df73fee878e685752e7863cab9368) allows the jfxNative
task to build a deb package. Not sure if this happens on other types of Linux. Definitely doesn't happen on macOS or Windows.
Tagging @JacisNonsense
Is there a stacktrace or something that comes with the failed build?
I'll run a build on my debian server soon and see if I can recreate the issue
I ran a build of f7efad2
(PR commit) and f7efad2~1
(Stable Commit, 1 commit before). Looking in ui/build/jfx/native/GRIP/app
you start to see some interesting things.
In the Stable Commit, 2 versions of GRIP are present, with 1 being the previous release candidate.
In the PR Commit, only 1 version of GRIP is present
Looking at the GRIP.cfg
of each, you see something that might be causing the issue.
--- STABLE GRIP.cfg ---
[Application]
app.name=GRIP
app.mainjar=GRIP-v1.5.2-x64.jar
app.version=1.5.1-rc1-x64
app.preferences.id=GRIP
app.mainclass=edu/wpi/grip/ui/Main
app.classpath=lib/core-v1.5.1-rc1-1-gf7efad2-all.jar:lib/slf4j-api-1.7.7.jar:lib/controlsfx-8.40.11.jar:lib/bcprov-jdk15on-1.51.jar:lib/jcip-annotations-1.0.jar:lib/jzlib-1.1.3.jar:lib/velocity-1.7.jar:lib/commons-collections-3.2.1.jar:lib/ecc-25519-java-1.0.1.jar:lib/commons-lang-2.4.jar:lib/annotations-3.0.1.jar:lib/jsr305-3.0.1.jar:lib/preloader-v1.5.1-rc1-1-gf7efad2.jar:lib/sshj-0.16.0.jar:lib/bcpkix-jdk15on-1.51.jar
app.runtime=$APPDIR/runtime
app.identifier=GRIP
[JVMOptions]
-XX:-OmitStackTraceInFastThrow
-Xmx200m
-XX:MaxNewSize=32m
-Djavafx.preloader=edu.wpi.grip.preloader.GripPreloader
[JVMUserOptions]
[ArgOptions]
--- PR GRIP.cfg ---
[Application]
app.name=GRIP
app.mainjar=GRIP-v1.5.2-x64.jar
app.version=v1.5.2-x64
app.preferences.id=GRIP
app.mainclass=edu/wpi/grip/ui/Main
app.classpath=lib/core-v1.5.1-rc1-1-gf7efad2-all.jar:lib/slf4j-api-1.7.7.jar:lib/controlsfx-8.40.11.jar:lib/bcprov-jdk15on-1.51.jar:lib/jcip-annotations-1.0.jar:lib/jzlib-1.1.3.jar:lib/velocity-1.7.jar:lib/commons-collections-3.2.1.jar:lib/ecc-25519-java-1.0.1.jar:lib/commons-lang-2.4.jar:lib/annotations-3.0.1.jar:lib/jsr305-3.0.1.jar:lib/preloader-v1.5.1-rc1-1-gf7efad2.jar:lib/sshj-0.16.0.jar:lib/bcpkix-jdk15on-1.51.jar
app.runtime=$APPDIR/runtime
app.identifier=GRIP
[JVMOptions]
-XX:-OmitStackTraceInFastThrow
-Xmx200m
-XX:MaxNewSize=32m
-Djavafx.preloader=edu.wpi.grip.preloader.GripPreloader
[JVMUserOptions]
[ArgOptions]
I think the key is in the app.mainjar
, app.version
and most importantly app.classpath
. app.mainjar
uses the correct GRIP jar, while on the previous version app.version
is mismatched. This isn't too big of an issue.
However, app.classpath
is where the issue stems. In both versions, the app.classpath
property is taking from the lib/core-v1.5.1-rc1-1-gf7efad2-all.jar
dependency (the GRIP core from the 1.5.1 release candidate). In the Stable Commit, 3 (!!!) versions of the GRIP core are included (as is the preloader)
In the PR Commit, only the 1 version of the GRIP core and preloader are included.
While it is the same version as listed in the app.classpath
config property, I have a feeling the issue is due to the absence of the other 2 versions.