GRIP icon indicating copy to clipboard operation
GRIP copied to clipboard

Building native .deb app is broken

Open SamCarlberg opened this issue 7 years ago • 4 comments

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

SamCarlberg avatar Jan 30 '17 20:01 SamCarlberg

Is there a stacktrace or something that comes with the failed build?

JaciBrunning avatar Jan 31 '17 09:01 JaciBrunning

Travis log

SamCarlberg avatar Jan 31 '17 13:01 SamCarlberg

I'll run a build on my debian server soon and see if I can recreate the issue

JaciBrunning avatar Jan 31 '17 13:01 JaciBrunning

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.

JaciBrunning avatar Jan 31 '17 14:01 JaciBrunning