Table of contents:

Understanding versions and the .m2 folder

Korlibs use Gradle and Kotlin-Multiplatform. All the libraries check and use the Maven Local .m2 folder first, then check jcenter and then bintray. All the projects have a file describing the versions.

In order to try changes locally you have to compile the libraries via gradle and publish them into your .m2 folder. You can either change your library or project to use the -SNAPSHOT version, or change the version property of the project your are compiling to match the required one. Since the other libraries and projects will use maven local, it will get a modified release version from the Maven Local repository.


Suppose we have these files:


# sytleguide

# version

# kotlinx


# sytleguide

# version

# kotlinx

Now consider you want to make a change as part of korio that affects korim and want to try it locally.

You can either:

  • Change the korim/ with korioVersion=1.9.9-SNAPSHOT.
  • Change the korio/ with version=1.9.8

In the end both work. I usually go for the second option and publish a patched non-snapshot version in my .m2 folder.

Building and publishing into the Maven Local .m2 folder

Publish all the libraries into maven local

This will compile all the targets and publish it to the .m2 folder. Since it compiles Kotlin/Native too, it will take some time.

./gradlew publishToMavenLocal

Publish the JVM and JS artifacts into maven local

For simple portable Kotlin/Common stuff, you can compile only JVM and maybe JS too and try in your own projects without compiling the Kotlin/Native targets.

In order to do so, you can execute the following command:

./gradlew publishJvmPublicationToMavenLocal publishJsPublicationToMavenLocal publishMetadataPublicationToMavenLocal publishKotlinMultiplatformPublicationToMavenLocal
  • publishJvmPublicationToMavenLocal - The JVM artifact
  • publishJsPublicationToMavenLocal - The JS artifact
  • publishMetadataPublicationToMavenLocal - The Kotlin/Common definitions artifact
  • publishKotlinMultiplatformPublicationToMavenLocal - The project without -suffix that points to per-platform artifacts

Using changes in Korge games

KorGE is split in three repositories:

KorGE games use versions in the gradle plugin repository. In fact, when making a patch in libraries other than korge itself, just a version bump + publishing there is enough.

You can publish the korge-plugins gradle plugin by calling:

./gradlew publishToMavenLocal

Alternatively you can check the dependency versions your project is using and change the specific-korlib/ you are building with a version matching your project.

Alternatively the korge-gradle-plugin checks your project searching for korimVersion, korgeVersion and so on. So you can force a specific korlib dependency version in your own project including a -SNAPSHOT version.

Unit testing using kotlin-test

To test just the JVM tests, you can call:

./gradlew jvmTest

NOTE: On IntelliJ as for this writing, there is a bug with the play icon gutter in multi-module multiplatform kotlin projects that doesn’t put the right submodule to the generated configuration. You can solve it as described here so you can easily debug and put breakpoints when running your tests.