I am trying to migrate my gradle to the gradle hierarchies. I am getting error:

kotlin {
    androidTarget() // <-- please register this Android target
}

When if I put

androidTarget()

gradle says

Unresolved reference: androidTarget

I cleaned my cache. And I have the template project from the Jetbrains wizzard tool which works just fine with androidTarget(). I am missing something I don't understand what exactly.

kotlin.version=1.9.20
agp.version=8.1.2
distributionUrl=https\://services.gradle.org/distributions/gradle-8.4-bin.zip

Any hints?

I would say restart the IDE, do a cleanup, remove the .gradle .idea directories. Ensure the plugins are up to date

I also have buildSrc module because in there I hosted my custom libraries version with just kotlin objects. Dunno if it anyhow breaking my build

In theory it shouldn't unless 1.9.20 introduced something new but I haven't read anything in regards. What plugins are you applying to that gradle project?

kotlin("jvm").version(kotlinVersion)
        kotlin("multiplatform").version(kotlinVersion)
        kotlin("plugin.serialization").version(kotlinVersion)
        kotlin("native.cocoapods").version(kotlinVersion)
        kotlin("android").version(kotlinVersion)

        id("com.android.application").version(agpVersion)
        id("com.android.library").version(agpVersion)
        id("org.jetbrains.compose").version(composeVersion)
        id("com.google.gms.google-services").version(googleServicesVersion)
        id("dev.icerock.mobile.multiplatform-resources").version(mokoResVersion)

Nothing specific. Unless Moko somehow breaks everything 😄

That's the root project but for the specific subproject where the error happens

plugins {
    kotlin("multiplatform")
    kotlin("plugin.serialization")
    kotlin("native.cocoapods")
    id("com.android.library")
    id("org.jetbrains.compose")
    id("app.cash.sqldelight").version(Versions.sqlDelight)
    id("dev.icerock.mobile.multiplatform-resources")
    id("com.google.gms.google-services")
}

shared gradle

I think you have to apply Android library plugin in it

Oh, right. In the template android application plugin is applied, and I still have .library

Or well, if it is your Android application module, the Android application plugin then

That will be weird. Because I have androidApp, iosApp and shared modules. If I apply android application in shared module it won't build my android, coz we can't have 2 android application modules

Exactly, Android application plugin cannot depend on another module that is an Android application too, it can only depend on Android library plugin, which is the case for shared or any other module you want to expose as a library

Not for the new jb wizzard: https://kmp.jetbrains.com/?_ga=2.16654134.1250543148.1699430153-1861656493.1680524595&_gl=1*1suz1id*_ga*MTg2MTY1NjQ5My4xNjgwNTI0NTk1*_ga_9J976DJZ68*MTY5OTQzMDE1Mi4xMTEuMS4xNjk5NDMwMTUyLjAuMC4w

Humm, sounds more like a bug to me

I don't know gradle that well so I could ignore templates

You can bring that up, about the application plugin applied to shared in their issue tracker or wherever is supposed to be reported

Okay. So what I learned: I can't use

androidTarget()

in

shared

because my shared has

id("com.android.library")

plugin. And seems like only android.application must be used for

androidTarget()

. Since I have androidApp module, I replaced in it the

kotlin("android")

plugin to

kotlin("multiplatform")

and added.

kotlin {
    androidTarget()

    sourceSets {
        val androidMain by getting {
            dependencies {
                implementation(project(":shared"))
            }
        }
    }
}

This setup can be seen in the compose-multiplatform-ios-android-template which I used to start the project. Seems like JB has 2 different templates at the moment and I have no clue where they are going. But seems like I can't migrate to the gradle hierarchies just now. At least it won't be easy coz I am not smart enough to do so. It builds for Android atm, will check iOS

Did you apply

applyDefaultHierarchyTemplate()

In your Gradle , and remove the Android plugins , see what happens. Check this build.gradle file. It works for me: https://github.com/pablichjenkov/component-toolkit/blob/master/component-toolkit/build.gradle.kts

/shared/build.gradle.kts:28:5: Unresolved reference: applyDefaultHierarchyTemplate

Although I can apply it for androidApp module

Potentially yeup, I have to refresh the gradle scripts right. There is probably a lot of stuff not needed anymore. I LL take a look later today

The Default Kotlin Hierarchy Template was not applied to 'project ':shared'':
Explicit .dependsOn() edges were configured for the following source sets:
[iosArm64Main, iosMain, iosSimulatorArm64Main, iosX64Main]

Consider removing dependsOn-calls or disabling the default template by adding
    'kotlin.mpp.applyDefaultHierarchyTemplate=false'
to your gradle.properties

And iOS won't build with that.

Well for iOS you have to replace createBy with gettingBy

But that won't work before?

applyDefaultHierarchyTemplate()

Exactly won't work before, is like a breaking change I guess

Seems like @Landry Norris has similar issue little bit below lmaop

I saw it 😀 , but yeah I need to remove the applyDefaultHirerchyTemplate. Seems not to be needed anymore

commonMain.dependencies {

I can't even import the .dependencies extension. Something is wrong with my gradle

What gradle version you are using by the way

distributionUrl=https\://services.gradle.org/distributions/gradle-8.4-bin.zip

this?

Seems good

I wonder if having buildSrc module breaks everything

Depending on what the code inside does. Unless it is not applying the plugins programatically

plugins {
    `kotlin-dsl`
}

repositories {
    mavenCentral()
}

kotlin {
    jvmToolchain(17)
}

It has this

Are you applying the plugins to each project by code? I think it overrides the scripts

I can't comment anything because I have my kotlin class Deps in there which I use everywhere to get the dependencies 😄

I ran into this in one module, and just left it with the deprecated

android

, which works for me. It just warns about deprecation.

👍🏻😀

I can't use

androidTarget()

in

shared

because my shared has

id("com.android.library")

plugin. And seems like only android.application must be used for

androidTarget()

This isn't true.

androidTarget()

can be applied to either a Android application or library.

I wonder if having buildSrc module breaks everything

This is very likely the case. It seems as if you have multiple versions of the Kotlin Gradle plugin being applied, an older version that doesn't have

androidTarget()

or

applyDefaultHierarchyTemplate()

.

Will remove buildSrc tomorrow and report

Gradle plugin versions is definitely one of the more painful aspects of Gradle. The build script needs to apply a specific version only once to the classpath. I use

buildSrc

in my library with version catalogs, which don't work well together out of the box currently, but this workaround helps. You can check out how I'm configuring the Kotlin Gradle plugin version in my library with

buildSrc

. It's being added to the classpath from the version catalog here. Then when it's applied, it doesn't use an explicit version.

Upd: Maybe I am wrong. Checking.

Humm 🤔 , well if it works it works 🤷🏻‍♂️ 😀

It starts working if I remove from my project SQLDelight plugin. But template project works with the same plugin

Generally plugins should be applied at the top-level project build.gradle with the explicit version in order to add to the classpath once. If the plugin doesn't need to be applied to the top level, then

apply false

can be added. Whenever a plugin is applied in a module build.gradle configurations, no version should be specified, as it will use the version introduced on the classpath already. I've found it best to follow this rule with all plugins, whether you think you're applying it only in a single module or not because it's possible other plugins have side effects of introducing another version where you don't expect. So by declaring it yourself at the top level, you maintain control of the version.

I do follow it, as you could see that on top, I have all others plugin following that idea. I don't remember why exactly I didn't do that with the only SQLDelight plugin, I planned to "fix it later". Shot into the foot