fix: code samples (#3697)

docs/topics/multiplatform-mobile/multiplatform-mobile-understand-project-structure.md

@@ -253,11 +253,12 @@ The configuration of Android library is stored in the `android {}` top-level blo
 
 ```kotlin
 android {
-    compileSdk = 29
-    sourceSets["main"].manifest.srcFile("src/androidMain/AndroidManifest.xml")
+    // A typical Android configuration, see https://developer.android.com/build for details.
+    //  For example:
+    namespace = "com.example.kotlinmultiplatformsandbox"
+    compileSdk = 33
     defaultConfig {
         minSdk = 24
-        targetSdk = 29
     }
 }
 ```
@@ -267,11 +268,12 @@ android {
 
 ```groovy
 android {
-    compileSdk 29
-    sourceSets.main.manifest.srcFile 'src/androidMain/AndroidManifest.xml'
+    // A typical Android configuration, see https://developer.android.com/build for details.
+    // For example:
+    namespace "com.example.kotlinmultiplatformsandbox"
+    compileSdk 33
     defaultConfig {
         minSdk 24
-        targetSdk 29
     }
 }
 ```
@@ -438,7 +440,6 @@ android {
     defaultConfig {
         applicationId = "org.example.androidApp"
         minSdk = 24
-        targetSdk = 29
         versionCode = 1
         versionName = "1.0"
     }
@@ -459,7 +460,6 @@ android {
     defaultConfig {
         applicationId 'org.example.androidApp'
         minSdk 24
-        targetSdk 29
         versionCode 1
         versionName '1.0'
     }

docs/topics/multiplatform/multiplatform-configure-compilations.md

@@ -43,10 +43,9 @@ kotlin {
 
 ```kotlin
 kotlin {
-    targets.jvm.compilations.all {
+    jvm().compilations.all {
         compilerOptions.configure {
-            sourceMap.set(true)
-            metaInfo.set(true)
+            jvmTarget.set(JvmTarget.JVM_1_8)
         }
     }
 }
@@ -59,8 +58,7 @@ kotlin {
 kotlin {
     jvm().compilations.all {
         compilerOptions.configure {
-            sourceMap.set(true)
-            metaInfo.set(true)
+            jvmTarget.set(JvmTarget.JVM_1_8)
         }
     }
 }
@@ -91,9 +89,11 @@ kotlin {
 
 ```groovy
 kotlin {
-    jvm().compilations.main {
-        compilerOptions.configure {
-            jvmTarget.set(JvmTarget.JVM_1_8)
+    jvm {
+        compilations.main {
+            compilerOptions.configure {
+                jvmTarget.set(JvmTarget.JVM_1_8)
+            }
         }
     }
 }

docs/topics/multiplatform/multiplatform-discover-project.md

@@ -55,8 +55,8 @@ When you create a multiplatform project, targets are added to the `kotlin` block
 
 ```kotlin
 kotlin {
-    jvm()    
-    js {
+    jvm()
+    js(IR) {
         browser {}
     }
  }

docs/topics/multiplatform/multiplatform-dsl-reference.md

@@ -779,9 +779,9 @@ kotlin {
                 api("com.example:foo-metadata:1.0")
             }
         }
-        val jvm6Main by getting {
+        val jvmMain by getting {
             dependencies {
-                implementation("com.example:foo-jvm6:1.0")
+                implementation("com.example:foo-jvm:1.0")
             }
         }
     }
@@ -799,9 +799,9 @@ kotlin {
                 api 'com.example:foo-metadata:1.0'
             }
         }
-        jvm6Main {
+        jvmMain {
             dependencies {
-                implementation 'com.example:foo-jvm6:1.0'
+                implementation 'com.example:foo-jvm:1.0'
             }
         }
     }
@@ -811,7 +811,8 @@ kotlin {
 </tab>
 </tabs>
 
-Additionally, source sets can depend on each other and form a hierarchy. In this case, the [dependsOn()](#source-set-parameters) relation is used.
+Additionally, source sets can depend on each other and form a hierarchy.
+In this case, the [`dependsOn()`](#source-set-parameters) relation is used.
 
 Source set dependencies can also be declared in the top-level `dependencies` block of the build script.
 In this case, their declarations follow the pattern `<sourceSetName><DependencyKind>`, for example, `commonMainApi`.

docs/topics/multiplatform/multiplatform-hierarchy.md

@@ -4,7 +4,7 @@ Multiplatform projects support hierarchical structures.
 This means you can arrange a hierarchy of intermediate source sets for sharing the common code among some, but not all,
 [supported targets](multiplatform-dsl-reference.md#targets). Using intermediate source sets has some important advantages:
 
-* If you're a library author and you want to provide a specialized API, you can use an intermediate source set for some,
+* If you're a library author, and you want to provide a specialized API, you can use an intermediate source set for some,
   but not all, targets – for example, an intermediate source set for Kotlin/Native targets but not for Kotlin/JVM ones.
 * If you want to use platform-dependent libraries in your project, you can use an intermediate source set
   to use that specific API in several native targets. For example, you can have access to iOS-specific dependencies,
@@ -38,6 +38,9 @@ It's a [template](#see-the-full-hierarchy-template) for all possible targets and
 To set up a hierarchy, call `targetHierarchy.default()` in the `kotlin` block of your `build.gradle(.kts)` file and list
 all of the targets you need. For example:
 
+<tabs group="build-script">
+<tab title="Kotlin" group-key="kotlin">
+
 ```kotlin
 @OptIn(ExperimentalKotlinGradlePluginApi::class)
 kotlin {
@@ -50,6 +53,25 @@ kotlin {
 }
 ```
 
+</tab>
+<tab title="Groovy" group-key="groovy">
+
+```groovy
+kotlin {
+    // Enable the default target hierarchy:
+    targetHierarchy.default {
+      
+    }
+
+    android()
+    iosArm64()
+    iosSimulatorArm64()
+}
+```
+
+</tab>
+</tabs>
+
 When you declare the final targets `android`, `iosArm64`, and `iosSimulatorArm64` in your code, the Kotlin Gradle plugin finds
 suitable shared source sets from the template and creates them for you. The resulting hierarchy looks like this:
 
@@ -76,6 +98,9 @@ To do so, apply the `by getting` construction for the source sets created with `
 
 Consider this example of a project with a source set shared between the `jvm` and `native` targets only:
 
+<tabs group="build-script">
+<tab title="Kotlin" group-key="kotlin">
+
 ```kotlin
 @OptIn(ExperimentalKotlinGradlePluginApi::class)
 kotlin {
@@ -104,6 +129,43 @@ kotlin {
 }
 ```
 
+</tab>
+<tab title="Groovy" group-key="groovy">
+
+```groovy
+kotlin {
+    // Enable the default target hierarchy:
+    targetHierarchy.default {
+      
+    }
+
+    jvm()
+    iosArm64()
+    // The rest of the other targets, if needed.
+
+    sourceSets {
+        commonMain {
+          
+        }
+
+        jvmAndNativeMain {
+            dependsOn(commonMain)
+        }
+
+        nativeMain {
+            dependsOn(jvmAndNativeMain)
+        }
+
+        jvmMain {
+            dependsOn(jvmAndNativeMain)
+        }
+    }
+}
+```
+
+</tab>
+</tabs>
+
 It can be cumbersome to remove `dependsOn` relations that are automatically created by the `targetHierarchy.default()` call.
 In that case, use an entirely [manual configuration](#manual-configuration) instead of calling the default hierarchy.
 
@@ -142,12 +204,27 @@ combinations:
 All shortcuts create similar hierarchical structures in the code. For example, you can use the`ios()` shortcut to create
 a multiplatform project with 2 iOS-related targets, `iosArm64` and `iosX64`, and a shared source set:
 
+<tabs group="build-script">
+<tab title="Kotlin" group-key="kotlin">
+
 ```kotlin
 kotlin {
-    ios() // iOS device and simulator targets; iosMain and iosTest source sets
+    ios() // iOS device and the iosX64 simulator target; iosMain and iosTest source sets
+}
+```
+
+</tab>
+<tab title="Groovy" group-key="groovy">
+
+```groovy
+kotlin {
+    ios() // iOS device and the iosX64 simulator target; iosMain and iosTest source sets
 }
 ```
 
+</tab>
+</tabs>
+
 In this case, the hierarchical structure includes the intermediate source sets `iosMain` and `iosTest`,
 which are used by the platform-specific source sets: