Set up publishing to Gradle Plugins Portal #47
Comments
|
We need to create a separate technical account. |
|
@marcphilipp really looking forward to using this plugin. Roughly when can we expect this plugin to be available in Gradle plugin repo? |
|
Just in case, publishing the plugin to Sonatype OSSRH (e.g. from Actions) might have nice side effects: |
We already have e2e tests with Central Repository executed on CI regularly, so it is already verified. However, as a person who remember times before Gradle Plugins Portal, I still like to have JARs released also there (although technically the majority of people use |
|
I didn't know. I thought that by default it uses only its own repo, but with extra coordinates set during the plugin release process it can leverage different groupId (path) to be compatible with releases to Maven Central. Good to know. Btw, GPP seems to be quite stable (as hosted by Gradle), but another Maven Central competitor - JCenter - has just announced sunrising with very tight deadlines (1 month to disable publishing and 3 months to complete shutdown) - https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ I see all the builds failing due to using artifacts published only to JCenter... Btw2, @marcphilipp hasn't Gradle been using Bintray under the hood for their GPP repo? |
Gradle Plugin Portal proxies "unknown" artifacts to Central, which enables using regular Here's a sample configuration that works with both "publishing to OSSRH", and "publishing to Gradle Plugin Portal": https://github.com/autostyle/autostyle/blob/85f539da6d6228517e300b72dd254ff61474b877/build.gradle.kts#L173-L182 |
It works with all repos if "plugin markers" are published alongside the main artifact: https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers
Some plugins are still hosted on Bintray, but when publishing to GPP they are stored in a separate repo. The Gradle team is currently working on a plan and an announcement for the sunset of JCenter.
Currently, it actually proxies JCenter which proxies Maven Central. |
|
@szpak With JCenter shutting down we should really try to release a first version of this plugin as soon as we can manage. |
|
Definitely, there is a momentum for that :). To facilitate the things I created a draft of the migration guide. Feel free to enhance it. |
|
Just wondering: do you think you could publish a snapshot plugin version to Central or prepare a staged repository? Probably it's time for me to try replacing GNSP+NPP to PP in https://github.com/vlsi/vlsi-release-plugins, and it would be easier to test if there was an artifact (e.g. snapshot plugin version or a staging repository). |
|
@vlsi With a Marc's help I was able to manually publish a SNAPSHOT version for you (production code as of b3ab16e) : It seems to work with minimal e2e-test project, but most likely you have some more complex scenarios to cover, so please let us know about spotted limitations :). Btw, you might need to add a snapshot repository to |
|
A technical user account is now set up to publish to https://plugins.gradle.org. @vlsi Do you have time to provide feedback within the next few days? Otherwise, we'd go ahead with the release. |
|
I'm testing this plugin with the Micronaut projects |
|
What is the way to retrieve the id of the staging repository? I need to propagate It looks like I can use I wonder if |
That is what I do anyway. I guess exposing the ID would help even if the plugin does not save/load it to a file. |
|
It looks like The migration to the new plugin does reduce the complexity which is great. For instance, |
I believe, it is covered by #19:
Let's move that discussion there, about details. |
|
@szpak So, let's ship it, shall we? |
|
How about bumping the version to 1.0 first? ;) |
It is viable, thus 1.0. It is much better than other 0.x plugins available, so it easily qualifies for 1.0 The subsequent ideas can come with 1.x or 2.x |
|
You have a gift of convincing ;). I would prefer not to bet when 2.0.0 will (have to) be released ;-). |
|
I changed the milestones and bumped the version accordingly. Now we just need to merge #54. 🙂 |
|
Publishing is set up and I will proceed with the release now. |
|
@marcphilipp Awesome... Thanks for the |
When someone from the Gradle team will approve the initial plugin release. Stay tuned. |
|
It‘s now been approved and is available on the Plugin Portal: https://plugins.gradle.org/plugin/io.github.gradle-nexus.publish-plugin |
|
I used the plugin to automate releases via GitHub Actions - and it works great. |
Preferable with the permission for @marcphilipp and @szpak to publish on their own (is it supported by GPP?). Alternatively, a separate technical account would have to be created (which would be also useful once the deployment is automated from the CI server).
Update. It would be good to beforehand prepare Maven coordinates to be able to release simultaneously to Maven Central, once/if it is implemented on day two.
The text was updated successfully, but these errors were encountered: