Fixed
Status Update
No update yet.
Comments
xa...@google.com
pa...@gradle.com
This can be worked around by defining Gradle plugin resolution strategies in `settings.gradle`, e.g. :
```
pluginManagement {
repositories {
gradlePluginPortal()
maven { url "https://jcenter.bintray.com/ " } // For AGP 2.x
maven { url "https://maven.google.com/ " } // For AGP 3.x
}
resolutionStrategy {
eachPlugin {
if(requested.id.id == "com.android.application") {
useModule("com.android.tools.build:gradle:${requested.version}")
}
}
}
}
```
then in `build.gradle`:
```
plugins {
id("com.android.application") version "2.2.3"
}
```
Resolving this issue will remove the need for all the boilerplate above in `settings.gradle`.
```
pluginManagement {
repositories {
gradlePluginPortal()
maven { url "
maven { url "
}
resolutionStrategy {
eachPlugin {
if(
useModule("com.android.tools.build:gradle:${requested.version}")
}
}
}
}
```
then in `build.gradle`:
```
plugins {
id("com.android.application") version "2.2.3"
}
```
Resolving this issue will remove the need for all the boilerplate above in `settings.gradle`.
xa...@google.com
We can look at publishing the marker. It's easier. We can do this in 3.1, and move the Studio templates to use this.
bu...@google.com
This is dupe of
ai...@gmail.com
Any updates about this issue?
Kotlin DSL reached RC already and 1.0 will be released with Gradle 5.0.
Kotlin DSL reached RC already and 1.0 will be released with Gradle 5.0.
je...@google.com
ai...@gmail.com
Any chance that marker will be published to maven.google.com ?
It's just create unnecessary boilerplate on plugin application for Kotlin DSL, and even for Groovy makes basic Android configuration simple.
It's also the problem for many other Gradle plugins from Google, but It's hard to report it even if Android plugin doesn't support plugins dsl
It's just create unnecessary boilerplate on plugin application for Kotlin DSL, and even for Groovy makes basic Android configuration simple.
It's also the problem for many other Gradle plugins from Google, but It's hard to report it even if Android plugin doesn't support plugins dsl
cm...@google.com
jm...@gmail.com
Hello,
this is super annoying,
please publish the required metadata to your `google()` repositories.
Not doing so means that using Gradle with Kotlin is painful.
Given that using Android Studio with Gradle and Groovy is *also* painful,
this leaves us with no good option.
this is super annoying,
please publish the required metadata to your `google()` repositories.
Not doing so means that using Gradle with Kotlin is painful.
Given that using Android Studio with Gradle and Groovy is *also* painful,
this leaves us with no good option.
jm...@gmail.com
plugins {
`kotlin-dsl`
`java-gradle-plugin`
`maven-publish`
}
gradlePlugin {
plugins {
create("xxx") {
id = "xxx"
displayName = "xxx"
description = "xxx"
implementationClass = "xxx"
}
}
}
pluginBundle {
website = "https://example.com "
vcsUrl = "https://example.com "
tags = listOf("android")
}
`kotlin-dsl`
`java-gradle-plugin`
`maven-publish`
}
gradlePlugin {
plugins {
create("xxx") {
id = "xxx"
displayName = "xxx"
description = "xxx"
implementationClass = "xxx"
}
}
}
pluginBundle {
website = "
vcsUrl = "
tags = listOf("android")
}
au...@google.com
Any updates here?
ga...@google.com
an...@bandlab.com
Thanks so much for fixing it!
Is there any chance that it will be backported to 4.1.x? Not super critical, but it would be possible to start using it earlier on upcoming 4.1 releases
Is there any chance that it will be backported to 4.1.x? Not super critical, but it would be possible to start using it earlier on upcoming 4.1 releases
ga...@google.com
AGP 4.1 will sadly not contain this as the change is non-trivial and 4.1 is right now in stabilization phase.
tr...@gmail.com
a short term workaround that is pretty low effort is to add AGP to your buildSrc api configuration. then it will be on your buildscript class path and any of the id's registered via the META-INF/gradle-plugins/*.properties will just work.
At least I think that is the mechanism at play, but i've been doing this for some time now without any issues, and not realizing that it was probably why the plugin block was working for me.
Roughly paraphrased from what I have in my current project, I didn't check this exact build script but I think that should do it.
//buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
repositories {
google()
}
dependencies {
api("com.android.tools.build:gradle:4.0.1")
}
Description
Android Plugin Version: any
To apply the Android Gradle plugin one has to do the following:
```
buildscript {
dependencies { classpath("com.android.tools.build:gradle:VERSION") }
repositories { google() }
}
apply plugin: "com.android.application"
```
This is the old way of applying plugins in Gradle. This issue is about allowing build authors to apply the Android Gradle plugin using the `plugins` block, as follows:
```
plugins {
id("com.android.application") version "VERSION"
}
```
Given that the Android Gradle plugins are not published to the Gradle Plugin Portal but to the Google repository, one would also have to add the following to his `settings.gradle` file:
```
pluginManagement {
repositories {
maven { url "
gradlePluginPortal()
}
}
```
The direct benefit is to use the new supported way of applying plugins in Gradle.
Another one is for the Gradle Kotlin DSL to be able to provide more IDE goodness to build authors by being able to react to the Android Gradle Plugin being applied and provide automatically generated type-safe accessors to the `android` extension.
To be able to do this, the plugins must be published alongside "plugin marker artifacts", see
This can easily be done using the `java-gradle-plugin` Gradle plugin, see