Improve gradle buildscript #3

solonovamax commented 2025年12月11日 00:12:50 +01:00 (Migrated from github.com)

Depends on #2

Changes:

• Use kotlin gradle DSL instead of groovy DSL
• Use version catalogs
  I've added multiple dependencies to it even though they're all included by org.java-gi:adw, as it shows off how to use bundles.
• Modernize some misc. things
• Add foojay toolchains resolver plugin
• Add some gradle properties that improve performance
• Bump java toolchain version to 25, as it's the latest LTS version (alternatively, I could go down to 21)

Depends on #2 Changes: - Use kotlin gradle DSL instead of groovy DSL - Use version catalogs I've added multiple dependencies to it even though they're all included by `org.java-gi:adw`, as it shows off how to use bundles. - Modernize some misc. things - Add foojay toolchains resolver plugin - Add some gradle properties that improve performance - Bump java toolchain version to 25, as it's the latest LTS version (alternatively, I could go down to 21)

jwharm commented 2025年12月11日 20:03:25 +01:00 (Migrated from github.com)

Most of these are welcome improvements, but the JDK needs to stay on 23, because that's the version that is included in the OpenJDK extension of the Freedesktop SDK that is used by the GNOME 48 Sdk. I'm pretty sure that JDK 25 will not work; the toolchain resolver can't help us in the offline build process of flatpak-builder.

Can you revert that back to JDK 23 and test if the flatpak build still works?

Most of these are welcome improvements, but the JDK needs to stay on 23, because that's the version that is included in the OpenJDK extension of the Freedesktop SDK that is used by the GNOME 48 Sdk. I'm pretty sure that JDK 25 will not work; the toolchain resolver can't help us in the offline build process of flatpak-builder. Can you revert that back to JDK 23 and test if the flatpak build still works?

UrtsiSantsi commented 2025年12月11日 23:27:08 +01:00 (Migrated from github.com)

Why not Gnome 49 and JDK 24?

Why not Gnome 49 and JDK 24?

solonovamax commented 2025年12月12日 04:45:19 +01:00 (Migrated from github.com)

Most of these are welcome improvements, but the JDK needs to stay on 23, because that's the version that is included in the OpenJDK extension of the Freedesktop SDK that is used by the GNOME 48 Sdk. I'm pretty sure that JDK 25 will not work; the toolchain resolver can't help us in the offline build process of flatpak-builder.

Can you revert that back to JDK 23 and test if the flatpak build still works?

hmmm, I see

tbh I personally would target 21 instead of 23, as even though 23 is the version packaged for gnome 48, 21 is the latest LTS

up to you

> Most of these are welcome improvements, but the JDK needs to stay on 23, because that's the version that is included in the OpenJDK extension of the Freedesktop SDK that is used by the GNOME 48 Sdk. I'm pretty sure that JDK 25 will not work; the toolchain resolver can't help us in the offline build process of flatpak-builder. > > Can you revert that back to JDK 23 and test if the flatpak build still works? hmmm, I see tbh I personally would target 21 instead of 23, as even though 23 is the version packaged for gnome 48, 21 is the latest LTS up to you

jwharm commented 2025年12月12日 21:24:46 +01:00 (Migrated from github.com)

Java-GI doesn’t support GNOME 49 yet.

Likewise, JDK 21 isn’t an option because Java-GI uses the new FFM introduced with JDK 22.

Java-GI doesn’t support GNOME 49 yet. Likewise, JDK 21 isn’t an option because Java-GI uses the new FFM introduced with JDK 22.

solonovamax commented 2025年12月13日 00:15:29 +01:00 (Migrated from github.com)

Java-GI doesn’t support GNOME 49 yet.

Likewise, JDK 21 isn’t an option because Java-GI uses the new FFM introduced with JDK 22.

ah, that sucks

in that case I'll revert to 23 later

> Java-GI doesn’t support GNOME 49 yet. > > Likewise, JDK 21 isn’t an option because Java-GI uses the new FFM introduced with JDK 22. ah, that sucks in that case I'll revert to 23 later

solonovamax commented 2025年12月13日 00:18:15 +01:00 (Migrated from github.com)

also, does flatpak have an environment variable or something I can use to detect when the build is happening in a flatpak environmen? because if yes then I'll change the extra repository to only be enabled when being built for a flatpak (alternatively, a kotlin extension function for this could be added to the plugin, similar to these: https://github.com/solo-studios/nyx/blob/master/src/main/kotlin/ca/solostudios/nyx/util/RepositoryHandlerExtensions.kt)

also, does flatpak have an environment variable or something I can use to detect when the build is happening in a flatpak environmen? because if yes then I'll change the extra repository to only be enabled when being built for a flatpak (alternatively, a kotlin extension function for this could be added to the plugin, similar to these: https://github.com/solo-studios/nyx/blob/master/src/main/kotlin/ca/solostudios/nyx/util/RepositoryHandlerExtensions.kt)

jwharm commented 2025年12月13日 11:36:55 +01:00 (Migrated from github.com)

You can check for the FLATPAK_ID environment variable. Flatpak-builder will set it to the id of the application.

You can check for the `FLATPAK_ID` environment variable. Flatpak-builder will set it to the id of the application.

jwharm commented 2025年12月13日 12:06:47 +01:00 (Migrated from github.com)

Two more things:

• Can you please disable the Gradle configuration cache in the gradle.properties file? I discovered that the flatpak-gradle-builder plugin doesn't work with the configuration cache enabled. (I'll fix that eventually.)
• I updated the dependency to the new java-gi release 0.13.1, can you please also do this in the version catalogue?

Two more things: - Can you please disable the Gradle configuration cache in the `gradle.properties` file? I discovered that the flatpak-gradle-builder plugin doesn't work with the configuration cache enabled. (I'll fix that eventually.) - I updated the dependency to the new java-gi release 0.13.1, can you please also do this in the version catalogue?

jwharm commented 2026年02月05日 21:33:09 +01:00 (Migrated from github.com)

Cleaning up stale PRs

Cleaning up stale PRs