Hi. I’m publishing my artifacts using Sonatype OSSRH. Now, I’m trying to get a plugin into the plugin portal. I’ve added a pluginsBundle section for my plugin with a maven coordinates section for the artifacts. However, the plugins seems to choke on the signatures (for security reasons, I guess? ;))
* What went wrong:
Execution failed for task ':publishPlugins'.
> Unknown artifact type with extension "asc" and classifier ""
You can only upload normal jars, sources jars, javadoc jars and groovydoc jars
to the plugin portal at this time.
Note that I don’t want to upload anything, this is done using OSSRH. I’d just like to add a pointer to the plugin to the database, so people can find it.
Raffael, there is no support in Gradle for publishing plugins hosted elsewhere. We don’t currently have any plans to add this kind of support either. Might you consider hosting your plugins on gradle.org instead of OSSRH?
I’m not sure about the implications. According to OSSRH ch.raffael.** is mine. I don’t know what happens, if artifacts from other sources and without my signature appear in there.
Generally, I’m quite happy with having a defined Maven-Repo-Space that’s mine and a single publishing channel to make artifacts available to everyone.
Raffael, is the problem that you’re not able to upload your asc artifacts to gradle.org?
I don’t know of any reason why it should be a problem to host your Gradle plugins on gradle.org, and your other artifacts on OSSRH, although I could be overlooking something. Can you see any issue with this?
In any case, we don’t support publishing plugins on gradle.org that are hosted elsewhere I’m afraid. I’m looking into why the publishing plugin isn’t able to upload asc artifacts, I hope this is the sole obstacle to your hosting your plugins on gradle.org.
Because the gradle org plugin repo is not the only place we are using.
If we use your plugin mechanism i can’t submit the same to sonatype and maven central.
So for us we must submit it to sonatype and would import it into plugins.gradle.
@x2on What do you gain by publishing Gradle plugins to other repositories? The canonical (and currently one supported) way is to publish them to gradle.org. If you adhere to this, publishing should simply work.
I’d really like to understand your process here, so I am wondering is if there are concrete reasons for us to support a workflow that involves publishing Gradle plugins to other repositories than our own. If there are, we will have to consider them.
I understand from previous discussions that we might support a workflow that involves staging to e.g. Sonatype, but those artifacts would be private and not published per se.
A lot of users of our plugins are not using the new plugin mechanism, they use central maven, jcenter or bitray for integrating gradle plugins.
That means we must support these repositories.
I think you should support integrating from the other repos - then you would get a lot of more plugins into the list.
For us it is no opinion to only support your repository.
I’m a bit confused - nothing stops you from publishing your plugins wherever you want. If you have users who only ever integrate plugins from maven central or jcenter or anywhere else, you can publish those plugins there. By the same token, if you have users who would like to use plugins published to the plugin portal, you can publish them to the plugin portal.
It took a lot of time to consolidate the repositories. Now, we’ve finally got Maven Central that contains it all. Finally, an artifact ID actually uniquely identifies an artifact. And it’s all there, if you’ve got Central in your repository list. No need for anything else.
By fragmenting repositories again, no one gains anything. On the contrary, we’re going back to repository hell. Why would anyone do that?
Raffael, is the problem that you’re not able to upload your asc artifacts to gradle.org?
Sonatype forces me to sign my artifacts. Which is a good thing, BTW. However, the plugin repository curiously won’t accept signed artifacts.
Also, some transparency would be nice. What is this plugin repository, anyway? What exactly do I do when using mavenCoordinates? What is the groupId of my plugin if not the groupId I specified in the build? There’s no information whatsoever about what that pluginPortal actually is, how it works, how it relates to maven repositories, nothing.
So, it’s absolutely possible that my problem is actually a phantom problem. Because I’m supposed to publish a plugin to some black box that I don’t understand and can’t find any documentation whatsoever.
@Raffael_Herzog We’ve created a work item for the signed artifacts issue, thanks for bringing this to our attention.
Regarding consolidation, sometimes you just have to be pragmatic. While a unified repository (e.g. Maven Central) is nice, what matters in the end is a functioning workflow. Our plugin portal is not simply another repository, it’s an integrated part of the Gradle services. So, my take on this is that it’s dubious whether continuing to discuss repository consolidation will bear any fruits, we have to be practical and focus on how to best evolve the Gradle Web services as a whole.
In my enterprise environment we use Nexus Pro to proxy all external repositories so that all artifacts (normal dependencies and plugins) can be 1) cached for resolution performance 2) cached for escrow reasons [builds must be reproducible for multiple years in the future] 3) artifacts can be scanned for license and security issues allowing us to manage their use.
How does one a) use a Maven repository manager (Nexus or JFrog) to proxy and sync the Gradle Plugin repository and b) use Maven coordinates to resolve Gradle plugins the same way we resolve other build dependencies ?
We still expose a maven-compatible repository structure from the plugin portal. Set your upstream repository in your local caching repository to point to https://plugins.gradle.org/m2/ and use the non-incubating syntax for applying the plugins, ie use a classpath dependency in the buildscript block and apply plugin: 'foo' rather than using the plugins block with an id.
@tomd
I ran across this discussion while searching around for how to add the gradle plugins repos to Nexus. I tried https://plugins.gradle.org/m2 but Nexus gives a 404.
If you try the link a browser, you do get a Page Not found error message.
We’ve been proxying https://plugins.gradle.org/m2 using Nexus for a while without any issues. I can’t speak to whether or not there is an intentional reason the index does not exist or whether the Plugin Portal maintainers are willing to add an index.
However, as a user, the lack of the index does not prevent you from proxying via Nexus. It only prevents you from turning on the feature that instructs Nexus to block the repository automatically due to this missing index. Turn this feature off for this one repository, and everything works with Nexus as expected.
