Using apply(from...) partial files android

[mtrakal]

Main file, which use apply from

build.gradle.kts

plugins {
    id("com.android.library")
    kotlin("android")
    kotlin("android.extensions")
    kotlin("kapt")
}
apply {
    from("$rootDir/config/include.gradle.kts")
}
android {
...
}

second file which includes single files for apply
include.gradle.kts

apply {
    from("$rootDir/config/exclude.gradle.kts")
    from("$rootDir/config/default.gradle.kts")
    from("$rootDir/config/testing/testing.gradle")
}

and in exclude.gradle.kts I have:

android {
  packagingOptions {
        exclude ("META-INF/DEPENDENCIES.TXT")
        exclude ("META-INF/LICENSE.TXT")
}}

But it failed on:

Script compilation errors:

  Line 01: android {
           ^ Unresolved reference: android

  Line 02:   packagingOptions {
             ^ Unresolved reference: packagingOptions

  Line 03:         exclude ("META-INF/DEPENDENCIES.TXT")
                   ^ Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
                       public fun Configuration.exclude(group: String? = ..., module: String? = ...): Configuration defined in org.gradle.kotlin.dsl

When I didn't use KTS file, but .gradle and Groovy and proper syntax, it works as expected. All excludes from the file are "included" into main build.gradle.kts into android and work as expected without any error.

Expected Behavior

Work same as when use Groovy

Current Behavior

Failed on: Unresolved reference: android

Your Environment

------------------------------------------------------------
Gradle 5.0
------------------------------------------------------------

Build time:   2018-11-26 11:48:43 UTC
Revision:     7fc6e5abf2fc5fe0824aec8a0f5462664dbcd987

Kotlin DSL:   1.0.4
Kotlin:       1.3.10
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          1.8.0_181 (Oracle Corporation 25.181-b13)
OS:           Windows 10 10.0 amd64

Android Studio 3.4 Canary 7
Build #AI-183.4284.148.34.5159543, built on December 3, 2018
JRE: 1.8.0_152-release-1248-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

kotlin: 1.3.11
using buildSrc

[JLLeitschuh]

The accessors aren't generated for script files that aren't the project script file.

[gkylafas]

Yes, I have the same experience with a multi-module project. I have put some common android {} declarations into a common-android.gradle file and apply it from each module's build.gradle.kts file. Its contents are:

android {
    compileSdkVersion 28
    buildToolsVersion "28.0.3"

    defaultConfig {
        minSdkVersion    15
        targetSdkVersion 28

        multiDexEnabled true
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

Unfortunately, I cannot convert this common file to Kotlin or I get the same Unresolved reference: android error as @mtrakal. On the other hand, if I keep the file to Groovy and apply it as such, it works correctly.

[JLLeitschuh]

You can declare the extension manually in your exclude.gradle.kts.

Full disclosure, I'm not an android developer.
However, if you put this logic in your build.gradle.kts file:

android {
  packagingOptions {
        exclude ("META-INF/DEPENDENCIES.TXT")
        exclude ("META-INF/LICENSE.TXT")
}}

From there, you should be able to jump to the declaration of the android variable.
It should look something like this:

/**
 * Configures the [android][[some long import here].AndroidExtension] project extension.
 */
fun Project.android(configure: [some long import here].AndroidExtension.() -> Unit) =
    extensions.configure("checkstyle", configure)

You can copy and paste that logic into the bottom of your exclude.gradle.kts and everything should work from there.

[mtrakal]

When we put everything from exclude.gradle.kts / common-android.gradle.kts to build.gradle.kts we don't need these files (exclude.gradle.kts / common-android.gradle.kts).
The reason, why we move some common parts to a single file is, that we use the same code in all modules...

like:
/mobile/build.gradle.kts contains apply(from("exclude.gradle.kts"))
/wear/build.gradle.kts contains apply(from("exclude.gradle.kts"))
/common/build.gradle.kts contains apply(from("exclude.gradle.kts"))
/sub-mobule1/build.gradle.kts contains apply(from("exclude.gradle.kts"))
/sub-mobule2/build.gradle.kts contains apply(from("exclude.gradle.kts"))
etc...

All modules use the same code and we don't want to edit on all submodules, so we use one file, which is (shared) applied in all modules.

In this files are just part of android code, every build.gradle.kts contains different parts inside and shared part from exclude.gradle.kts / common-android.gradle.kts

[fuzzyweapon]

@mtrakal - please check out this documentation. When you are working in an applied script (aka a script plugin), type-safe accessors are not yet available (for standard built-ins and for applied plugins).

The way kotlin-dsl makes these available (android { }, etc) is by generating them and including them on the main build script's classpath automatically. For plugins applied through the plugins block, it also generates accessors so that they can be used just-in-time (I'm probably over-simplifying).

So when you are not in a main build script (settings, init, applied) or when you apply a plugin outside of the plugins block (i.e. apply()), you will not have access to type-safe accessors of the DSL.

What @JLLeitschuh is suggesting is a way to manually pull in the code for the accessors you want.
You do this by putting some sample code of what you want in the main build file (or the target code itself, temporarily), use your IDE to go to where the accessors are written/generated, and then manually paste the accessor code into the script where type-safe accessors are not automatically on the classpath.

After doing this, you will be able to run the configuration code using those accessors (aka, using the the DSL, android { }).

Note that just because you pull in an accessor for android { }, it will not automatically give you access to all the parts configurable in android. In the case of the exclude.gradle.kts script, you would need to pull in the accessors for both android { } and android.packingOptions { } (using the same method).

[matejdro]

One problem I see with this is that when iterating through all subprojects, top script has no way of statically knowing of what type of project is each project in extensions. There is different extension class for library projects and app projects for example, but both are named android.

[mkobit]

Also related to #427

[kiratheone]

I've tried what @JLLeitschuh suggest but didn't work

val Project.`android`: AppExtension
    get() =
    (this as ExtensionAware).extensions.getByName("android") as AppExtension

fun Project.`android`(configure: AppExtension.() -> Unit): Unit =
    (this as ExtensionAware).extensions.configure("android", configure)

[JLLeitschuh]

@kiratheone A bit more information would be useful.

[Smouking]

Hellow!
Use Gradle 5.2.1 and simple scripts:
build.gradle.kts

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    kotlin("jvm") version "1.3.11"
}

group = "com.smouking"
version = "1.0-SNAPSHOT"

repositories {
    jcenter()
}

dependencies {
    compile(kotlin("stdlib-jdk8"))
}

tasks.withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "1.8"
}

apply(from ="ktlint.gradle.kts")

ktlint.gradle.kts

import org.jlleitschuh.gradle.ktlint.KtlintPlugin

buildscript {
    repositories {
        gradlePluginPortal()
    }

    dependencies {
        //classpath(kotlin("gradle-plugin", version = "1.3.21"))
        classpath("org.jlleitschuh.gradle:ktlint-gradle:7.1.0")
    }
}
//The plugins {} block must not be used here

apply<KtlintPlugin>()

It failed on:

* Exception is:
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/gradle/plugin/KotlinSourceSet

If uncomment classpath(kotlin("gradle-plugin", version = "1.3.21"))
It failed on:

* Exception is:
Caused by: java.lang.IllegalStateException: Could not find any convention object of type KotlinSourceSet.

because KotlinSourceSet. loaded diferent Classloader.

How to fix it?

[matejdro]

This has nothing to do with the issue at hand...

[Smouking]

Why not? I can not use apply(from=) for configure my project.
Should I do another issue?

[BulatMukhutdinov]

@JLLeitschuh my external gradle.kts file

apply(plugin = "com.android.application")

/**
 * Configures the [android][com.android.build.gradle.internal.dsl.BaseAppModuleExtension] extension.
 */
fun org.gradle.api.Project.`android`(configure: com.android.build.gradle.internal.dsl.BaseAppModuleExtension.() -> Unit): Unit =
        (this as org.gradle.api.plugins.ExtensionAware).extensions.configure("android", configure)

I get an error

Script compilation errors:

  Line 11: fun org.gradle.api.Project.`android`(configure: com.android.build.gradle.internal.dsl.BaseAppModuleExtension.() -> Unit): Unit =
                                                               ^ Unresolved reference: android

  Line 12:         (this as org.gradle.api.plugins.ExtensionAware).extensions.configure("android", configure)
                                                                              ^ None of the following functions can be called with the arguments supplied: 
                                                                                  public abstract fun <T : Any!> configure(p0: Class<TypeVariable(T)!>!, p1: Action<in TypeVariable(T)!>!): Unit defined in org.gradle.api.plugins.ExtensionContainer
                                                                                  @Incubating public abstract fun <T : Any!> configure(p0: String!, p1: Action<in TypeVariable(T)!>!): Unit defined in org.gradle.api.plugins.ExtensionContainer
                                                                                  public abstract fun <T : Any!> configure(p0: TypeOf<TypeVariable(T)!>!, p1: Action<in TypeVariable(T)!>!): Unit defined in org.gradle.api.plugins.ExtensionContainer

2 errors

[nicusorflorin]

any update on this? when can we expect a proper fix for the accessors?