Fix Snap build

[ebbez]

There were some problems with the Snap build causing it to fail:

1. The Snap build/pack could not find Gradle in the build-step because the path still pointed to Gradle 8.6
2. The Gradle build was executing tasks for builds with Windows components (downloadJres, downloadGStreamer, createQueleaExe64), but those tasks could not be removed because the copyToDist task would fail since it (copyToDist) expects the Windows components to be present.
3. It could not compile the Java application because only a JRE was downloaded instead of the JDK.
4. /build/quelea/parts/quelea/build/dist/ didn't seem to exist when testing to pack the Snap with snapcraft pack.
5. The .desktop-file contained a Version=2019 entry, but when I was building Flatpaks earlier this year, I noticed there was a warning stating that the Version entry was incorrectly used. It appears it can only be used to specify the .desktop-file specification version, not the application's version.

Fixed by:

1. Changing the path of Gradle to the downloaded gradle-9.1.0/bin
2. Added an if-statement to copyToDist to only unzip a Windows JRE when present.
3. Replaced the JRE with a JDK in the build-step, and separately downloads a JRE in the stage-step.
4. Replaced the path with /root/parts/quelea/build/dist/. I'm unsure at this time if this is the correct path when it builds on Ubuntu/Canonical/Snapcraft servers/runners, but it worked when locally executing snapcraft pack which I believe simulates a normal build environment because it makes a VM in which the Snap gets packed/built.
5. Removed the Version= entry from the .desktop file.
6. Replaced the jar/ directory with app/ to be more clear what is contained inside the directory.

[ebbez]

Btw the reason for resorting to an absolute path instead of an environment variable to get the build-stage files was because neither $SNAPCRAFT_PART_BUILD or $SNAPCRAFT_PART_BUILD_WORK exist (in the stage-step atleast).

[ebbez]

In order to skip having to use absolute paths I just also discovered you could copy in the build-step to the stage-step (/remove the stage-step override completely):

    override-build: |
      wget -O jdk.tar.gz https://cdn.azul.com/zulu/bin/zulu25.28.85-ca-fx-jdk25.0.0-linux_x64.tar.gz
      mkdir jdk
      tar -xf jdk.tar.gz -C jdk --strip-components 1

      wget -O gradle.zip https://services.gradle.org/distributions/gradle-9.1.0-bin.zip
      unzip gradle.zip

      PATH=$PATH:$(pwd)/jdk/bin:$(pwd)/gradle-9.1.0/bin
      JAVA_HOME=$(pwd)/jdk

      gradle -Djava.net.useSystemProxies=true -Dnightly=true -Dversionsuffix=CI-UNSTABLE clean labelcheck jar copyToDist

      wget -O jre.tar.gz https://cdn.azul.com/zulu/bin/zulu25.28.85-ca-fx-jre25.0.0-linux_x64.tar.gz
      mkdir jre 
      tar -xf jre.tar.gz -C jre --strip-components 1

      mkdir -p $SNAPCRAFT_STAGE/app/jvm
      cp -a dist/. $SNAPCRAFT_STAGE/app
      cp -a jre/. $SNAPCRAFT_STAGE/app/jvm
    override-prime: |
      snapcraftctl prime
      mkdir app
      cp -a $SNAPCRAFT_STAGE/app/. app/.
      chmod +x $SNAPCRAFT_PRIME/app/launch.sh
      glib-compile-schemas usr/share/glib-2.0/schemas/

This might be a cleaner solution

[ebbez]

Build and boot are succesful. Seems to function normally.

[berry120]

LGTM, looks like we might need to upgrade the wrapper again though to be in line with #700?

[ebbez]

Yep that sounds logical. Just tested it and it seemed to build succesfully on WSL2 Ubuntu machine.

[ebbez]

(Builds/results of previous commits were tested on a real Ubuntu PC, I just didn't feel like rebooting my computer just now :P )

[ebbez]

Thanks, should a push/new commit to master automatically trigger a build for the edge channel?

[berry120]

Yes :-)

[ebbez]

Hmm it doesn't seem to have done that. Maybe it's got 'blocked' since the last pushes were causing errors?

[berry120]

It looks like it ran, but: [image: image.png] ...not immediately sure why, there's nothing obvious in the logs.

…

On Sat, 10 Jan 2026 at 10:19, Ebbe Zeinstra ***@***.***> wrote: *ebbez* left a comment (quelea-projection/Quelea#698) <#698 (comment)> Hmm it doesn't seem to have done that. Maybe it's got 'blocked' since the last pushes were causing errors? — Reply to this email directly, view it on GitHub <#698 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ6JDMANUUINWYCBBJPCJL4GDG3JAVCNFSM6AAAAACQB4PJB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZSGMZTMNRUGM> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- Thanks, Michael

[berry120]

Ok, I've run a build manually and looks like that's worked, so was probably a temporary Snapcraft glitch.

…

On Sat, 10 Jan 2026 at 10:46, Michael Berry ***@***.***> wrote: It looks like it ran, but: [image: image.png] ...not immediately sure why, there's nothing obvious in the logs. On Sat, 10 Jan 2026 at 10:19, Ebbe Zeinstra ***@***.***> wrote: > *ebbez* left a comment (quelea-projection/Quelea#698) > <#698 (comment)> > > Hmm it doesn't seem to have done that. Maybe it's got 'blocked' since the > last pushes were causing errors? > > — > Reply to this email directly, view it on GitHub > <#698 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABZ6JDMANUUINWYCBBJPCJL4GDG3JAVCNFSM6AAAAACQB4PJB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZSGMZTMNRUGM> > . > You are receiving this because you modified the open/close state.Message > ID: ***@***.***> > -- Thanks, Michael

-- Thanks, Michael

[ebbez]

Ok cool, thanks! :-)