chore: Upgrade project to Gradle and AGP 9 and korlibs 7.0.0-SNAPSHOT by malliaridis · Pull Request #2364 · korlibs/korge

malliaridis · 2026-05-10T21:06:05Z

Description

As we move forward and plan to upgrade our libraries and tools, major releases require larger refactorings. This PR addresses the major upgrade of Gradle to 9.4.1 and Android Gradle Plugin to 9.1.1, as well as korlibs to 7.0.0-SNAPSHOT.

Solution

The current AGP upgrade requires a split of the android application plugin and therefore the android entrypoint. This forces us to split the sandbox module into two modules, one is the shared sandbox stuff, and the other the androidApp entrypoint module.

The PR removes the usage of the complex setup in buildSrc and follows a more gradle-native approach. The existing plugins korge-gradle-plugin, korge-gradle-plugin-common and korge-gradle-plugin-settings are moved to a sub-directory and included as composite builds.

The archive directory is completely removed, as it is not a meaningful part of the project (it is still available in the git history).

The workflows are flattened to clearly distinguish between each os-specific workflow and their tasks. I chose here duplication for readability and simplicity. Multiple tasks are replaced with just gradlew check.

I have compared buildSrc with the current korge-gradle-plugin. There are minimal differences, and with the move to the composite build, most changes are now identical, with korge-gradle-plugin containing more stuff (probably more up-to-date). Therefore, removing buildSrc seems like removing a whole duplicated module. You can generate a diff with the IDE and see the actual differences listed to confirm this.

Open Tasks

Comment the removals and what they were doing, how it is done / configured now and where to find the new configs
Add notes for potential differences
Update github workflows to work with new project configurations
Fix / Include e2e modules in builds

Additional Information

Important Note when trying this PR: In order to build and test this PR you have to use Android Studio or Gradle from the CLI. None of the current IntelliJ versions support this build (AGP 9 to be precise) and you have to disable the Android plugin in IntelliJ if you want the Gradle sync to succeed (not tested yet in this project). The AGP versions is not supported, and the proposal of downgrading to 9.0.0-alphaX is not solving the sync issue either. Support for AGP 9 was planned in Q1 of 2026, but we still waiting for it.

Improtant Note 2: To run the checks successfully, you have to use a local publication of korlibs with the changes from korlibs/korlibs#201.

Note that the increase of lines of code comes from the API files. In reality the lines of code are reduced by a lot.

malliaridis · 2026-05-11T12:37:11Z

I removed ABI validation from this PR to enable it in a separate PR. ABI validation was not enabled before, and it adds a couple thousand lines of code, which hid the actual impact of this PR.

jobe-m · 2026-05-12T14:58:37Z

Tests are failing with:

> Could not resolve all dependencies for configuration ':korge-core:jsNpmAggregated'.
         > Could not find org.korge.korlibs:korlibs-io-stream:7.0.0-SNAPSHOT.
           Searched in the following locations:
             - file:/home/runner/.m2/repository/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/maven-metadata.xml
             - file:/home/runner/.m2/repository/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/korlibs-io-stream-7.0.0-SNAPSHOT.pom
             - https://repo.maven.apache.org/maven2/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/maven-metadata.xml
             - https://repo.maven.apache.org/maven2/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/korlibs-io-stream-7.0.0-SNAPSHOT.pom
             - https://dl.google.com/dl/android/maven2/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/maven-metadata.xml
             - https://dl.google.com/dl/android/maven2/org/korge/korlibs/korlibs-io-stream/7.0.0-SNAPSHOT/korlibs-io-stream-7.0.0-SNAPSHOT.pom
           Required by:
               project ':korge-core'

We could publish 7.0.0-SNAPSHOT to Maven Central (snapshot) from the feature branch in Korlibs (korlibs/korlibs#201) and add here also the maven-snapshot URI to Gradle, right?

malliaridis · 2026-05-12T21:00:10Z

We could publish 7.0.0-SNAPSHOT to Maven Central (snapshot) from the feature branch in Korlibs (korlibs/korlibs#201) and add here also the maven-snapshot URI to Gradle, right?

Yes, a snapshot release would allow us to run the build for this one. We probably have to add the snapshots repository to the dependency management repositories, but that should be simple enough.

malliaridis · 2026-05-13T18:49:16Z

-          '--enable-unsafe-webgpu', // Enable WebGPU
-          '--enable-features=Vulkan', // Enable Vulkan
-          '--no-sandbox', // Optional: Helps to run Chrome in certain CI environments
-          '--disable-dev-shm-usage', // Optional: Helps to avoid issues with /dev/shm partition in certain CI environments
-          '--headless', // Ensures that Chrome runs in headless mode
-          //'--disable-gpu', // Optional: Disable hardware GPU acceleration (useful in some CI environments)
-          '--remote-debugging-port=9222' // Optional: Allows remote debugging


I have copied the karma configuration from the korlibs repo and moved it to each module that needs one, which is a minimal configuration.

However, these flags are used for development / tests, and could proove useful in the future. I would reenable them afterwards if we noticed issues with the workflows.

malliaridis · 2026-05-13T18:54:48Z

+            api(projects.korge)
+            api(libs.kotlinx.benchmark.runtime)


Many of our dependencies are added as API dependencies, which are passed down transitively and potentially leak unwanted (re)sources. I would address and discuss this in separate PRs and keep the dependencies for now the same.

jobe-m · 2026-05-15T14:00:20Z

@malliaridis I realized that then running ./gradlew publishToMavenLocal only the "engine" part of Korge is published. The projects under korge-gradle-plugins are not published. Could it be that the publish part is missing in their build.gradle.kts files?

malliaridis · 2026-05-15T15:04:35Z

@malliaridis I realized that then running ./gradlew publishToMavenLocal only the "engine" part of Korge is published. The projects under korge-gradle-plugins are not published. Could it be that the publish part is missing in their build.gradle.kts files?

You are right, it is not included because we are using compositeBuild (included builds) for the plugins. This means they are not direct sub-projects of the project, and therefore not included. This allows us to prepare the plugins as plugins before the project is initialized, and then use them as plugins in the same project (e.g. in sandbox).

For the publication of the plugins you can and should instead use the module-specific task:

./gradlew :korge-gradle-plugins:korge-gradle-plugin:publishToMavenLocal

The current state / builds of the plugins do not have a version yet (they use unspecified), but I will add one before finalizing this PR.

And I believe korge-core did not have a publication, right? If not, let me know and I will add that back.

malliaridis · 2026-05-15T15:07:54Z

Should we use a separate release cycle for the plugins and therefore use a different version variable than korge itself from now on, or should it be shared (at least this PR)?

jobe-m · 2026-05-15T17:12:08Z

For the publication of the plugins you can and should instead use the module-specific task:
./gradlew :korge-gradle-plugins:korge-gradle-plugin:publishToMavenLocal

Thanks, perfect! This is all I need :)

Should we use a separate release cycle for the plugins and therefore use a different version variable than korge itself from now on, or should it be shared (at least this PR)?

Releasing them separately is OK. I would keep the version in sync for now as long as both come out of the same repo. Later we can decouple the version. But I would suggest that both have the same major version, to keep them aligned.

jobe-m · 2026-05-15T17:14:32Z

And I believe korge-core did not have a publication, right? If not, let me know and I will add that back.

Yes, we need to release korge-core also. At least it was published in 6.0.0.

jobe-m · 2026-05-17T14:04:14Z

Version info missing: version = libs.versions.korge.get()

jobe-m · 2026-05-17T14:07:52Z

Shouldn't we change here both places to use Java 25?

As mentioned in other comment, for higher compatibility, Java 21 may be the better option right now. But I am open to discuss and test an upgrade to 25 as well. :)

I guess I mixed it up with the need to use/update to Java 25 in Intellij IDEA/Android Studio because of Gradle 9.4.1. But here the Java version means something else, right? So, it's fine to go with Java 21 :)

The selection of the java version mainly depends on the libraries used in the game projects. When going with the lets say Java 25, any other dependency added to the project needs to support that version as well, otherwise it won't compile. As of today, I believe the highest compatibility is reached with 21, not 25 (yet).

I guess we can upgrade to 25 in the next major release though, or allow the user to configure it (best option) and only fallback to 21 if the user is not interested in setting it. But I would address that outside the scope of this PR.

jobe-m · 2026-05-17T14:10:32Z

-        //androidTestImplementation 'com.android.support.test:runner:1.0.2'
-    }
+private fun Project.configureAndroidExecutable(isKorge: Boolean) {
+    project.plugins.apply("com.android.application")


It looks like we cannot use this plugin with the new AGP version. Remove line?

The android application plugin cannot be configured together with the multiplatform plugins. This is the migration requirement for AGP 9.

Just removing the "apply" here would simply not apply the plugin. This would probably break the rest of the configuration in this file. Upgrading AGP. to 9 in 7.0 will require users to also migrate their projects to not use android application plugin in the same module as the multiplatform shared code.

Providing a migration guide is required here.

Whether we need to configure the android executable function though is another topic. I would like to cleanup the korge-plugin, but in a separate move, and remove any configuration that we should not be countable for (e.g. project details that are configured in gradle per project).

This requires some better planning and investigation of what is configured and how in this plugin.

Upgrading AGP. to 9 in 7.0 will require users to also migrate their projects to not use android application plugin in the same module as the multiplatform shared code.

Korge is "hiding" the Gradle stuff from the (game) developer. So I guess there are not many of us which will have any additional Gradle code outside of Korge in their game project configuration. I even remember that adding another dependency to a library from Maven Central (as I did for Fleks) required to "go" through Korge and use a provided Gradle plugin function dependencyMulti("io.github.quillraven.fleks:Fleks:2.14", registerPlugin = false). So I guess there will not be the need for a migration guide.

If "com.android.application" cannot be used - as it seems - then let's remove it and add what is necessary to get Korge working again :)

Yeah, this is what I found problematic with the current plugin setup. We are basically "redefining" what gradle already does. We have like an alias for everything just to make it "the korge way", without any special reason. Sure there was or is a reason, but it can definitely be solved differently, more gradle-like, allowing users who already are familiar with gradle use their existing knowledge. So korge would be just another plugin that turns your project into a game, similar to what the compose plugin does (turning your project to a frontend multiplatform application).

This is a very good point. I would also like that Korge does not add its "own" Gradle stuff. This is hard to understand and to maintain. I am fine if we find a good solution for 7.0.0 (or 8?) which just uses Gradle in a minimalistic way. This also makes maintenance much easier.
When there is already a good approach (compose plugin) than why not utilizing it also for Korge.

jobe-m · 2026-05-17T14:20:13Z

LibraryExtention is deprecated and needs to be exchanged with something else. But I could not figure it out and I could not get it working to use this in a downstream project wiht kproject (e.g. in korlibs/korge-hello-world example).

The replacement for it is KotlinMultiplatformAndroidLibraryExtension now. I have updated the file accordingly, further deprecations need to be identified and updated. Thanks for finding this one. I will also take a look at other repos once this is no longer in draft state.

jobe-m · 2026-05-17T14:23:45Z

-    }
-}
+group = "org.korge.engine"
+version = rootProject.libs.versions.korge.get()

 mavenPublishing {
    configure(JavaLibrary(javadocJar = JavadocJar.Empty(), sourcesJar = true))


It looks like we need to change sourcesJar = true so something else?

I haven't figured out what this line configures yet. I will have to look it up to better understand it. I only took it over from previous configuration. I'll share my findings here.

jobe-m · 2026-05-17T14:24:42Z

+javaSourceCompatibility = "21"
+javaTargetCompatibility = "21"


Change java version to 25?

25 may be the next LTS, but I have seen some lack of support. So it would probably be too early to go with Java 25.

What would should consider is replacing these two values with toolchain configuration, rather than setting source and target compatibility values (old way setting them).

jobe-m · 2026-05-17T14:26:29Z

+[plugins]
+buildconfig = { id = "com.github.gmazzo.buildconfig", version.ref = "buildconfig" }
+android-multiplatform-library = { id = "com.android.kotlin.multiplatform.library", version.ref = "android-gradle-plugin" }
+android-application = { id = "com.android.application", version.ref = "android-gradle-plugin" }


android-application is not used or deprecated, so I guess we can remove it?

android-application is used by :korge-sandbox:androidApp. This plugin is not compatible with the rest of the multiplatform plugins, and causes all the trouble of splitting existing gradle modules into two separate modules.

korge-sandbox needs to be adjusted also. It uses Korge basically the same (?) way as a standalone Korge game project would use Korge. I guess it can be used to quickly test Korge features without the need of releasing Korge locally and using it in another project.

You may try the sandbox again and let me know if it works for JVM now. I have enabled and configured a few things to make it work again (tested on MacOS). There are basically 3 executable tasks:

jvmRun

runJvm

runJvmAwtSandbox

jobe-m · 2026-05-17T14:28:59Z

I put all my findings in comments to not loose them and maybe contribute. They are from trying to get my game project working with 7.0.0-SNAPSHOT. But I cancelled it now due to lack of knowledge how to proceed and time.

jobe-m and others added 7 commits May 8, 2026 17:54

Update Android Java and iOS config to support Korlibs 7.0.0-SNAPSHOT

4924213

Migrate korge gradle files and project structure

1006c7b

Move source files to correct directories

ac319db

Add all build directories to gitignore

f90628e

Fix build and test issues

3eed8ad

Remove unused code

e930626

Add missing files

448f079

malliaridis added enhancement cleanup dependencies Pull requests that update a dependency file breaking-change labels May 10, 2026

malliaridis added 3 commits May 11, 2026 15:34

Disable ABI validation for now

184d3fe

Remove unused android configurations for benchmarks module

f23c2d9

Simplify checks workflows

7c511da

malliaridis added 2 commits May 11, 2026 16:28

Fix unsupported version warning

e5a4e6e

Skip tests that use Lock on unsupported targets

98ae242

malliaridis added 2 commits May 13, 2026 19:42

Add maven snapshots repository for korlibs modules

5cdfff6

Remove e2e tests as modules require migration

1f8af2b

jobe-m reviewed May 14, 2026

View reviewed changes

Comment thread gradle/libs.versions.toml Outdated

malliaridis commented May 15, 2026

View reviewed changes

malliaridis added 2 commits May 15, 2026 18:27

Add versions to plugin publications

4650742

Update vanniktech publication plugin to 0.36.0

a0e25cc