-
Notifications
You must be signed in to change notification settings - Fork 40
Publish plugin on Gradle Plugin Portal #300
Comments
+1 from me Please Google Engineers add your plugin to https://plugins.gradle.org/ Benefit: Instead of the current ceremony...
just...
... for the user. |
It is really hard to get it working. I spent an our trying to make it work with kts until I found this. Funny to find my solution in a bug report! |
yeah it might take a moment, the plugin makes some assumptions about plugin loading order than need to be worked out. |
If publishing to the Gradle plugin portal isn't feasible it can still go into the // build.gradle.kts
plugins {
id("com.google.cloud.tools.appengine") version "2.+"
}
// settings.gradle.kts
pluginManagement {
repositories {
gradlePluginPortal()
google()
}
} |
@loosebazooka any news? |
Slow to pull the trigger here. Sonatype/maven-central provide us with download metrics and they are useful in determining (for us) the amount of time to invest in projects, the gradle plugin portal maintainers haven't updated their download data in a while, and don't seem to have any obvious plans of offering it. We are waiting on that, however we could still update the plugin to use the right apis. |
That'd be a great first step for sure. You may want to reach out to the Android Studio team, they have a direct line with Gradle and may help you out there :) |
This should be fixed in |
while |
Great news, thanks @loosebazooka :) I don't see it on the Gradle Plugins portal though. Surely not having to declare a
(Assuming you kept the ID |
Yeah it's not in the gradle plugins portal. See rationale here(as much as one might disagree): #300 (comment) I'm looking at trying to make it so that we don't HAVE to use resolution strategy, but that would involve some changes to our release process that are not ready. Docs here for now: https://github.com/GoogleCloudPlatform/app-gradle-plugin#using-plugins-block |
Ah I thought when you said "it's done" you meant publishing on the plugins portal, as that's what the issue was originally about :) My bad, misunderstood the meaning. |
Sorry, yeah, I may have missed a few details when I first commented. |
@loosebazooka , I'm not sure if you aware, however, Gradle plugins can be used without "resolution strategy" in case they have a special-named artifact. In order for Note: Gradle Plugin Portal proxies requests to jcenter/mavenCentral, so the end-users won't need to add repositories to resolve the plugin. Here's a sample: https://search.maven.org/artifact/com.github.autostyle/com.github.autostyle.gradle.plugin/3.1/pom Relevant documentation: https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers |
Right, I guess we just haven't gotten to it. Updating the plugin release process is something we need to do. If I recall correctly, gradle publishes the xyz.gradle.plugin as a simple pom with a single dependency that is the full artifact? I think what we would do is just publish the artifact to both artifact ids? Or have some two step publish to maven central? |
That is right.
I see you use |
What about the sonatype release? Two separate workflows? Not sure that they allow you to upload a single bundle with separate artifact ids? |
@loosebazooka , as I understand you do not want to publish to Gradle Plugin Portal, so would you please close the issue? |
Closing as not planned. |
Plugin not available through gradle
plugins
block.Existing workaround https://docs.gradle.org/current/userguide/plugins.html#example_plugin_resolution_strategy
The text was updated successfully, but these errors were encountered: