Any clues on this one folks <https://stackoverflow...

# gradle

[robertoestivill]

Any clues on this one folks https://stackoverflow.com/questions/57627119/android-subprojects-with-kotlin-dsl ?

[Marc Knaup]

Try adding the Android library plugin to the parent build.gradle.kts with apply false.

Only if a plugin is in the plugins block synthetic accessors like android {} will get created.

[robertoestivill]

Added

plugins {
  id(Plugin.androidApp) apply false
}

right under the top level build.gradle buildscript block

And error message in child module is slightly different

app/build.gradle.kts' line: 4

* What went wrong:
Plugin [id: 'com.android.application'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)

[Marc Knaup]

You’ll need both, the Android library plugin and the Kotlin Android plugin

[Marc Knaup]

the latter depends on the former

[robertoestivill]

Just tried with both in the parent build file. Same result.

This doesn't seem right to me, why would I apply a plugin to all modules, even when some of them are not of that type ?

[Marc Knaup]

You don’t apply them if you use apply false, you merely load them.
Unless the Android plugin is loaded Gradle doesn’t know that it should create plugin-specific Kotlin accessors like android { … }.

[robertoestivill]

Ah ok, that makes sense.

[Marc Knaup]

Unfortunately it doesn’t seem to create the accessors unless the plugin is indeed applied 😕

[robertoestivill]

Yep, looks like it. Although the error message is complaining in the child module app/. So I'm wondering if I missing something else here 🤔

[Marc Knaup]

You need to actually apply the plugins in the submodules

[Marc Knaup]

but still, I can’t use android {} in the parent with apply false

[Marc Knaup]

https://docs.gradle.org/current/userguide/kotlin_dsl.html#type-safe-accessors

[robertoestivill]

It's applied in all the children modules already

[mbonnin]

It's definitely not as good but maybe you can do without typesafety until there's a solution:```extensions.getByName("android") as BaseAppModuleExtension```

[mbonnin]

Also: shouldn't you invoke project.android in the root gradle file and not just android ?

[efemoney]

Posted to SO 🙂

[robertoestivill]

Thanks! That worked. Now I am stuck on a different problem with the parent build.gradle.kts not finding the com.android.application plugin for it to use, even though it's in the buildscript block

buildscript {
  repositories {
    google()
    mavenCentral()
  }
  dependencies {
    classpath(Classpath.androidGradle)
    classpath(Classpath.kotlinGradle)
  }
}

plugins {
  id(Plugin.androidApp) version "3.4.2" apply false
  id(Plugin.kotlinAndroid) version "1.3.41" apply false
}

project-root/build.gradle.kts' line: 22

* What went wrong:
Plugin [id: 'com.android.application', version: '3.4.2', apply: false] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'com.android.application:com.android.application.gradle.plugin:3.4.2')
  Searched in the following repositories:
    Gradle Central Plugin Repository

[efemoney]

When you use the plugins block, it is evaluated first (in my opinion, even before buildscript block). As you can see Gradle tries to resolve the plugins from the core (/bundled) plugins and then from the gradle plugin repository. But the android (and kotlin) gradle plugin(s) is(are) not published to the gradle plugin portal 🙂. To aid Gradle in resolving the plugin you will need to add this block to the project-level settings.gradle(.kts) file.

pluginManagement {
  repositories {
    google()
    mavenCentral()
    gradlePluginPortal() // 
  }
  resolutionStrategy {
    eachPlugin {
      if (requested.id.id.startsWith("com.android.")) useModule(Plugin.androidApp)
      // ... add declaration for kotlin gradle plugin too
    }
  }
}

[Marc Knaup]

Don't use a version number for the android plugin because you already pass it when loading via classpath.
Afaik it will cause Gradle to look in the repos instead where it can't find the plugin

[robertoestivill]

@Marc Knaup removing the version did not solve the issue. It just failed with the same error, but shorter, as it could try to fetch the plugin from the repository without having a version

[robertoestivill]

@efemoney that moved things forward a bit. However now I'm facing a different issue and it is starting to look like going down the rabbit hole.

Build file '/application/build.gradle.kts' line: 4
An exception occurred applying plugin request [id: 'com.android.application', artifact: 'com.android.tools.build:gradle:3.4.2']
> Failed to apply plugin [class 'org.gradle.api.plugins.BasePlugin']
   > Extension of type 'BaseExtension' does not exist. Currently registered extension types: [ExtraPropertiesExtension, DefaultArtifactPublicationSet]

[Marc Knaup]

I've lost track of how your project is structured 😅

I'm using buildSrc to load the Android Gradle Plugin, not buildscript. No idea if there's a difference.

[efemoney]

@robertoestivill
The BasePlugin class you need to check for is the android one 😄 and it has a generic type parameter (before agp version 3.6.0-alpha06) so

import com.android.build.gradle.BaseExtension
import com.android.build.gradle.BasePlugin

and then plugins.withType<BasePlugin<*>> { ... }

[efemoney]

@Marc Knaup I was gonna get there next after walking @robertoestivill through his case.

[robertoestivill]

I guess it got to the point where I should explain a bit better the way things are structured and what I'm trying to accomplish

Basically, I have a multimodule project with a layout similar to (simplified)

application/       -> android application module (depends on all features)
buildSrc/          -> kotlin dsl enabled
feature-a/         -> android library
feature-b/         -> android library
feature-c/         -> android library
...
build.gradle       -> parent gradle
settings.gradle

buildSrc was created to expose kotlin constants with the dependencies coordinates, versions, android configuration, etc. No logic was included in buildSrc, just constants that we wanted to define in a single place.
All gradle files were written in Groovy until I started working on this.
The tricky part that triggered this conversation and the StackOverflow issue is in the parent build.gradle.
This script configured all the children modules common android { } blocks in a single place, allowing children modules to just apply plugins and dependencies, and have a single point of configuration for all ocurrences of the android plugin.

The current state of things was not intentionally decided or designed so I understand your concerns about how is this working.
However, this is more the result of the evolution of the codebase coming from people like me, not really experts on gradle, other than something we created from scratch or consciously decided on.

Now, I have migrated all the children modules build scripts to kotlin and that works fine as long as I don't migrate the parent groovy build.gradle, but I am struggling to replicate the behavior that the parent script had on it's equivalent kotlin version.

Sorry for the confusion, and thanks for the help so far 🙂

[efemoney]

Did you fix things with this https://kotlinlang.slack.com/archives/C19FD9681/p1566915674242400?thread_ts=1566572282.222900&amp;cid=C19FD9681?

[robertoestivill]

@efemoney yes! it moved one step forward, now onto deal with Crashlytics haha. But yes, at least the build gets configured and the execution is started properly.

Will love to understand more about all this, as I'm definitely not understanding the logic behind all this configuration. Any resource to read on? Thanks again

[efemoney]

The Gradle documentation is pretty complete with all of this information. For kotlin dsl I always recommend starting at the kotlin dsl primer https://docs.gradle.org/current/userguide/kotlin_dsl.html

[robertoestivill]

Thanks again @efemoney this has been quite informative, will take a look at that 👍

[gildor]

Also, this doesn't really solve the problem of generated accessors

buildSrc also can help with it, if you move configuration to precompiled script plugin