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.