gradle / plugin-portal-requests

Gradle Plugin Portal issues and requests.

Gradle Plugin Portal Requests

Features and Bugs

Please add your Gradle Plugin Portal bug reports or feature requests by opening an issue.

Help with the plugin portal

Deleting a plugin or version

If you've published a version of your plugin to the plugin portal and you need to remove it, you have 7 days from the time the plugin is published to delete it. After that, you will need to open an issue. Please let us know which plugin and version you would like to delete and how we can verify that you're the owner of the plugin.

We really want to avoid deleting existing plugins when possible since this may break existing builds. If you've stopped development on your plugin or have published it under a new name, please open an issue and we can mark the plugin deprecated and point users to the new plugin.

Transferring ownership

If you've handed development of a plugin to someone else, we can transfer that plugin to the new account.

Open an issue and provide:

• A link to the plugin to be transferred
• Who you would like to transfer the plugin to (user name or link to their user profile)

You may need to provide proof you're the current owner.

Changing links, tags or description

To change the links, tags or description of your plugin, open an issue with a link to the plugin and what changes you would like to see.

Changing account information

If you need to delete your user account or change the email associated with it, please open an issue.

If you'd like to keep your email private, please email us at [email protected].

plugin-portal-requests's Issues

Plugin 'com.github.turansky.yfiles'. Remove request for versions '0.0.15' & '0.0.18'

Plugin Id

com.github.turansky.yfiles

Current Plugin Owner

turansky

Context

Remove please following versions of plugin:

• 0.0.15
• 0.0.18

Ownership transfer of com.google.osdetector

Plugin Id

com.google.osdetector

Current Plugin Owner

zhangkun83

Expected Plugin Owner

voidzcy (both the Plugin Portal username and Github username)

Context

com.google.osdetector is the companion project of com.google.protobuf of which @voidzcy is already the maintainer.

Remove "io.arrow-kt.arrow" plugin

Plugin Id

io.arrow-kt.arrow

Current Plugin Owner

rachelmcarmena

Note

All the content from https://plugins.gradle.org/m2/io/arrow-kt/ can be deleted, arrow-kt included.

Context

We're going to publish this plugin from a different account and with a different roadmap. We don't want to keep the current versions.

Thanks in advance!! 👍

Plugin 'com.github.turansky.yfiles'. Update tags request

Plugin Id

com.github.turansky.yfiles

Current Plugin Owner

turansky

Context

Update please tags for plugin.
New tags:

• yfiles
• kotlin
• kotlin-js
• javascript

No longer able to publish Gradle plugin because of wrong "Invalid plugin ID 'plugins'"

I'm trying to publish the plugin in the plugin module of that project
which as its build.gradle.kts here.
I already published a version of a previous revision successfully on the Gradle portal.

I'm running that command: ./gradlew :plugin:publishPlugins.

Expected Behavior

Just like previous versions, I can publish my plugin smoothly on the Gradle portal as long as the version doesn't already exist.

Current Behavior

Getting that error at build time:

* What went wrong:
Execution failed for task ':plugin:publishPlugins'.
> Invalid plugin ID 'plugins': Plugin IDs should be namespaced, e.g. 'com.example.plugins'

Context

That's preventing me from publishing a new version of my Gradle plugin.

Steps to Reproduce

Clone the affected revision of the project, and run ./gradlew :plugin:publishPlugins.

Your Environment

I'm using macOS 10.14.6.

Plugin publishing delays

Plugin publishing seems to be stalled or not happening... Or perhaps the message about 24h turn around produced by the plugin is not accurate, and should be updated?

The request should be processed within the next 24 hours, at which point you will be contacted via email.

See: https://discuss.gradle.org/t/plugin-pending-approval-since-before-xmas/34390/3

Enforce all plugin uploads to Gradle Plugin Portal require PGP signature

Expected Behavior

Published plugins should have cryptographic signatures, so they can be verified at the consumer side.

Note: this is related to gradle/gradle#10443, however gradle/gradle#10443 is a Gradle part for verification of checksums/signatures, however Gradle Plugin Portal forbids publishing of PGP signatures.

So this issue is to enforce (or "strongly advice") plugin authors to publish PGP signatures along with regular plugin jars.

Current Behavior

Current plugins are published without clear signatures, so consumers cannot tell if the jar was produced by a trusted party or not.

Note: SHA signatures do not help with that.
In other words, every time a plugin updates, it would require consumers to lookup a new SHA and bake that in a build script.

If published plugins had signatures, then build script could reference "a set of trusted PGP keys", so it won't require to update the SHA sums on each version update.

Context

I'm trying to implement a reproducible and trusted build (e.g. for https://github.com/apache/jmeter ).

The sad thing is Plugin Portal does not require plugin authors to publish signatures, so it really hard to check if a specific plugin jar is trusted or not.

For instance: https://plugins.gradle.org/m2/org/gradle/kotlin/plugins/1.2.9/
Is there a way to verify if plugins-1.2.9.jar corresponds to plugins-1.2.9-sources.jar?
Who was the author of those artifacts?

Plugin Author-Editable Description, Release Notes and Hashtags

Please can we make changes to our own plugin descriptions, release notes and tags?

Expected Behavior

I specify a description and tags in the pluginBundle{} block of the build script that I use to publish my plugin. I expect for the description and tags to be displayed on the plugin portal pages exactly as I specify them in the build script.

Current Behavior

The description and tags that I specify in the pluginBundle{} block of the build script that I use to publish my plugin, are ignored by the rendering process of the plugin portal.

The text that I specify in the build script does not get displayed. I therefore need to request that someone on the Gradle team manually make the changes I require on my behalf.

Context

As a plugin developer, I am continually adding features and making other changes to my plugin.

Typically, the textual descriptions of the new features also need to be updated accordingly. Likewise for the hashtags — which prospective users might use as metadata keywords on which to search for plugins that provide the capabilities they're looking for.

It would help users find plugins that meet their needs quicker if the descriptions, tags and other metadata that describes plugins are all updated the instant the latest version of the plugin is published to the plugin portal.

Having some kind of mechanism that allows plugin authors to update their own description and tags themselves would be super valuable to end-users and plugin authors.

Such a feature would be valuable for the Gradle team too, since I imagine manually updating static web page content is not the most efficient use of your time either.

Requesting non-audited access to my plugins

i used to be able to publish my plugins without approval, after properly identifying myself to you.

now i'm back to being audited. can this be fixed? i'm running my own repo for publishing other related artifacts and it'd make sense for me to move the plugin there if auditing is required for each release.

ideally i'd be authorized to publish under com.github.lanchon.* ids.

thanks!

Please remove https://plugins.gradle.org/plugin/io.jumpco.open.kfsm.gradle.viz-plugin

I have decided to make the name a little shorter by remove .gradle from the id.

Plugin Id

https://plugins.gradle.org/plugin/io.jumpco.open.kfsm.gradle.viz-plugin

Current Plugin Owner

[email protected] or github @corneil

Context

I have decided to make the name a little shorter by remove .gradle from the id.

The same plugin is published with a shorter name.

publishPlugin task failed (again), leading to partial publication and non-activation

Expected Behavior

Executing ./gradlew publishPlugins should work.

Current Behavior

It does not always.

Context

I have the following output:

> Task :publishPlugins
Publishing plugin com.autonomousapps.dependency-analysis version 0.20.0-SNAPSHOT
Publishing artifact build/libs/dependency-analysis-gradle-plugin-0.20.0-SNAPSHOT.jar
Publishing artifact build/libs/dependency-analysis-gradle-plugin-0.20.0-SNAPSHOT-sources.jar
Publishing artifact build/libs/dependency-analysis-gradle-plugin-0.20.0-SNAPSHOT-javadoc.jar
Publishing artifact build/publish-generated-resources/pom.xml
Activating plugin com.autonomousapps.dependency-analysis version 0.20.0-SNAPSHOT

> Task :publishPlugins FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 41s
8 actionable tasks: 6 executed, 2 up-to-date

Publishing build scan...
https://gradle.com/s/maph5wytn6bni

It looks like it failed at Activating plugin..., because I cannot see v0.20.0 of the plugin in the portal.

Steps to Reproduce

Sometimes it just happens 🤷‍♂️

This is the project: https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin

Your Environment

Ubuntu 18.04, Gradle 6.1.1, apparently poor home network.

Remove versions 4.2.0, 4.3.0, and 4.3.1 of the biz.aQute.bnd.gradle plugins from portal

Versions 4.2.0, 4.3.0, and 4.3.1 of the biz.aQute.bnd.gradle plugins are published in the plugin portal with pom files which prevent them from being properly used.

See #9.

A fix from @marcphilipp (bndtools/bnd#3811) now enables us to publish with the proper pom to the plugin portal.

I need to republish versions 4.2.0, 4.3.0, and 4.3.1 of the biz.aQute.bnd.gradle plugins, so please delete those versions from the plugin portal.

Note: I just published version 5.0.0 of the biz.aQute.bnd.gradle plugins using the fix from @marcphilipp, so that version is correct and does not need to be deleted.

Plugin Id

There are 3 plugin ids biz.aQute.bnd, biz.aQute.bnd.builder, and biz.aQute.bnd.workspace for each of the 3 versions, 4.2.0, 4.3.0, and 4.3.1, that need to be deleted.

Current Plugin Owner

I am the plugin owner.

Context

See #9 (comment) where it is suggested I open this bug to request deletion of the already published plugins with invalid pom files.

Allow users to report vulnerable plugins

Allow users to report vulnerable plugins.

Expected Behavior

Allow users of the plugin portal to report vulnerable plugins using the portal itself.

Current Behavior

Currently, the process seems to be to raise an issue on this project which is time consuming.

Synchronize `jruby-gradle-core-plugin` with to the plugin portal

See https://discuss.gradle.org/t/syncing-a-new-plugin-from-bintray/32184

Transfer ownership for com.equisoft.standards.kotlin plugin to equisoft

Plugin Id

com.equisoft.standards.kotlin

Current Plugin Owner

chrisv-equisoft

Expected Plugin Owner

equisoft

Context

I created a personal account to deploy our plugin, but I don't
have any options to set up a business profile. As such I would like to transfer ownership to our business managed account.

Thank you!

Request to delete a SNAPSHOT version deployed to the portal

Plugin Id

jp.skypencil.spotbugs.snom

Current Plugin Owner

@KengoTODA

Context

Deployed 2.0.0-SNAPSHOT version by my mistake, so want to request to remove it.
Refer https://discuss.gradle.org/t/request-to-delete-a-snapshot-version-deployed-to-the-portal/34430 for detsil.

Remove plugins `dev.gradleplugins.*`

Plugin Id

• dev.gradleplugins.java-gradle-plugin
• dev.gradleplugins.groovy-gradle-plugin
• dev.gradleplugins.kotlin-gradle-plugin

See: https://plugins.gradle.org/search?term=dev.gradleplugins

Current Plugin Owner

• @lacasseio (aka me)

Context

The Kotlin one never worked as expected due to how the kotlin-dsl plugin is integrated with Gradle. The other two are being released under Bintray for now until they become more stable for a wider audience.

Another reason why they should be removed is the plugin mostly doesn't work because the original TestKit test was all wrong due to how TestKit work and was hiding bugs after publication.

Cannot publish the biz.aQute.bnd version 4.3.0 plugins because the server says the version already exists

Expected Behavior

Since version 4.3.0 of the plugins are not visible in the plugin repo, I expect the plugin to be published.

Current Behavior

> Task :publishPlugins FAILED
Publishing plugin biz.aQute.bnd.builder version 4.3.0

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> Failed to post to server.
  Server responded with:
  Artifact [group: biz.aQute.bnd, artifactId: biz.aQute.bnd.gradle,version: 4.3.0, classifier: None, extension: pom] has already been published

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':publishPlugins'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$3.accept(ExecuteActionsTaskExecuter.java:166)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$3.accept(ExecuteActionsTaskExecuter.java:163)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:191)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:156)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:108)
        at org.gradle.api.internal.tasks.execution.ResolveBeforeExecutionOutputsTaskExecuter.execute(ResolveBeforeExecutionOutputsTaskExecuter.java:67)
        at org.gradle.api.internal.tasks.execution.ResolveAfterPreviousExecutionStateTaskExecuter.execute(ResolveAfterPreviousExecutionStateTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:94)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:95)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:102)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:43)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:355)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:343)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:336)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:322)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker$1.execute(DefaultPlanExecutor.java:134)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker$1.execute(DefaultPlanExecutor.java:129)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:202)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:193)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:129)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.RuntimeException: Failed to post to server.
Server responded with:
Artifact [group: biz.aQute.bnd, artifactId: biz.aQute.bnd.gradle,version: 4.3.0, classifier: None, extension: pom] has already been published
        at com.gradle.publish.ResponseUtil.assertValidResponse(ResponseUtil.java:17)
        at com.gradle.publish.OAuthHttpClient.send(OAuthHttpClient.java:78)
        at com.gradle.publish.PublishTask.doSignedPost(PublishTask.java:333)
        at com.gradle.publish.PublishTask.publishToPortal(PublishTask.java:215)
        at com.gradle.publish.PublishTask.publish(PublishTask.java:72)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:49)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:42)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:717)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:684)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$5.run(ExecuteActionsTaskExecuter.java:476)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:461)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:444)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$200(ExecuteActionsTaskExecuter.java:93)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:237)
        at org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$1(ExecuteStep.java:33)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:33)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:26)
        at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:58)
        at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:35)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:48)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:33)
        at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:39)
        at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:73)
        at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:54)
        at org.gradle.internal.execution.steps.CatchExceptionStep.execute(CatchExceptionStep.java:35)
        at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:51)
        at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:45)
        at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:31)
        at org.gradle.internal.execution.steps.CacheStep.executeWithoutCache(CacheStep.java:208)
        at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:70)
        at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:45)
        at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:49)
        at org.gradle.internal.execution.steps.StoreSnapshotsStep.execute(StoreSnapshotsStep.java:43)
        at org.gradle.internal.execution.steps.StoreSnapshotsStep.execute(StoreSnapshotsStep.java:32)
        at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:38)
        at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:24)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:96)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:89)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:54)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:38)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:76)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:37)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:36)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:26)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:90)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:48)
        at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:69)
        at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:47)
        at org.gradle.internal.execution.impl.DefaultWorkExecutor.execute(DefaultWorkExecutor.java:33)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:140)
        ... 34 more


* Get more help at https://help.gradle.org

BUILD FAILED in 5s

Context

Well I cannot publish newer versions of the Bnd Gradle plugins on the Gradle Plugin portal. So I direct users to use Maven Central or JCenter instead.

Steps to Reproduce

I use the script at https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/publish.gradle to publish the Bnd Gradle plugins to the Gradle Plugin portal so I can publish the same binaries built in our CI build that are on Maven Central and JCenter to the Gradle Plugin portal.

Your Environment

------------------------------------------------------------
Gradle 5.6.3
------------------------------------------------------------

Build time:   2019-10-18 00:28:36 UTC
Revision:     bd168bbf5d152c479186a897f2cea494b7875d13

Kotlin:       1.3.41
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.14 compiled on March 12 2019
JVM:          1.8.0_222 (Azul Systems, Inc. 25.222-b10)
OS:           Mac OS X 10.15 x86_64

A Deleted Plugin Can Still Be Successfully Applied In A Project

A plugin that I deleted from the plugin portal several days ago, is still reachable over the external network.

Expected Behavior

When I delete a plugin from the portal, I expect that it would not be possible to apply that version of the plugin in a project and have the deleted version successfully resolved over the internet.

Current Behavior

While one user reported that his attempted usage of the deleted plugin failed to be found in the portal, my own usage of the plugin was successfully downloaded from the portal somehow.

Context

I deleted com.lingocoder.mrjar 0.0.16 about four days ago. Two days ago, @jdneo, maintainer of the vscode-java-test project confirmed that — at least for him — that particular version of mrJar was indeed not available from the plugin portal.

Today, four days after I deleted it, a project in which I'd applied that version appears to be able to reach the deleted version over the internet somehow.

Steps to Reproduce

1. Login to the plugin portal
2. Delete a version of the plugin that was published within the last seven days
3. Four days later, apply the deleted version of the plugin in a project
4. Observe that the plugin was apparently not actually deleted...

...You can see in the recording that the build scan reports the access to the plugin as being apparently through the portal (External). You can also see in the recording, that I've checked the settings.gradle of the project(s) in question. I believe that I have clearly confirmed that the projects are not configured to use a local publication of the plugin. I presume that is what External means in the build scan.

Your Environment

Gradle 6.0-rc-2
OpenJDK 12
Windows amd64
com.lingocoder.mrjar 0.0.16

Remove plugin 1.4 version request

Plugin Id

https://plugins.gradle.org/plugin/org.jboss.gm.analyzer and version 1.4

Current Plugin Owner

I am ( under 'rnc' at Gradle Plugin repo).

Context

I upload

https://plugins.gradle.org/plugin/org.jboss.gm.analyzer
https://plugins.gradle.org/plugin/org.jboss.gm.manipulation

(which are from https://github.com/project-ncl/gradle-manipulator )

Unfortunately analyzer had a bad 1.4 release pushed to it by mistake. Would it be possible to delete the 1.4 please?

Tags update for xyz.ronella.simple-git plugin

Plugin Id
xyz.ronella.simple-git

Current Plugin Owner
rcw3bb

Context
Add the following tags:

• repository
• source
• source-control
• versioning
• simple-git

Publication fails and plugin cannot be published anymore

Hello,

Current Behavior

I tried to publish plugin org.siouan.frontend with version 2.1.0 few minutes ago. Publication fails with the Javadoc artifact, and a 403 error. Now I can't publish again the plugin because Gradle reports it already exists, although the version is not visible in the portal yet, and I cannot delete it.

Steps to Reproduce

Below you will find Gradle output for the two publication attempts:

D:\...\frontend-gradle-plugin>gradlew publishPlugins
Starting a Gradle Daemon, 2 incompatible and 2 stopped Daemons could not be reused, use --status for details

> Task :publishPlugins
Publishing plugin org.siouan.frontend version 2.1.0
Publishing artifact build/libs/frontend-gradle-plugin-2.1.0.jar
Publishing artifact build/libs/frontend-gradle-plugin-2.1.0-sources.jar
Publishing artifact build/libs/frontend-gradle-plugin-2.1.0-javadoc.jar

> Task :publishPlugins FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> java.io.IOException: Unexpected HTTP response while uploading D:\...\frontend-gradle-plugin\build\libs\frontend-gradle-plugin-2.1.0-javadoc.jar: 403 Forbidden

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 7s
9 actionable tasks: 7 executed, 2 up-to-date

D:\...\frontend-gradle-plugin>gradlew publishPlugins

> Task :publishPlugins FAILED
Publishing plugin org.siouan.frontend version 2.1.0

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> Failed to post to server.
  Server responded with:
  Plugin: 'org.siouan.frontend', version: '2.1.0' exists already. It was created: 2020-04-27 06:31:45.18

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
9 actionable tasks: 2 executed, 7 up-to-date

Your Environment

Gradle : 6.3
JDK : 11.0.6 64 bits
O/S : Windows 10 Pro

My requests:

• Can you remove any 2.1.0 artifacts already published so as I can try again publishing?
• Can you also update the plugin description on the portal please? Actually, the description is "Integrate your frontend NPM/Yarn build into a Gradle build.", while it is expected to be "Build Node.js, npm, Yarn applications with Gradle."

Thanks in advance for your help!
BR,
Vincent

Remove org.kordamp.gradle.kordamp-parentpom:1.16.0

Plugin Id

org.kordamp.gradle.kordamp-parentpom 1.16.0

Current Plugin Owner

aalmiray

Context

I encountered an error when publishing "org.kordamp.gradle.kordamp-parentpom 1.16.0"

> Task :publishPlugins
Could not reuse POM from pluginMaven publication because mavenCoordinates() was used
Publishing plugin org.kordamp.gradle.kordamp-parentpom version 1.16.0
Publishing artifact build/libs/kordamp-parentpom-1.16.0.jar

> Task :publishPlugins FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> java.net.ConnectException: Operation timed out (Connection timed out)

The network problem may have been on my side. A second attempt led to the following error

> Task :publishPlugins FAILED
Could not reuse POM from pluginMaven publication because mavenCoordinates() was used
Publishing plugin org.kordamp.gradle.kordamp-parentpom version 1.16.0

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> Failed to post to server.
  Server responded with:
  Plugin: 'org.kordamp.gradle.kordamp-parentpom', version: '1.16.0' exists already. It was created: 2020-05-30 14:45:37.233

However the GPP lists 1.15.0 as latest. I can't access 1.16.0 to delete it a try again.

Could you delete version 1.16.0 so that I can try a upload again?
Thank you.

Allow sorting and filtering on the plugin search results page

Allow sorting and filtering on the plugin search results page.

Expected Behavior

Allow sorting and filtering on the plugin search results page so that one can quickly find the plugin they are looking for, by eliminating noise.

Current Behavior

No such functionality is offered.

Remove version `2.0` of plugin `dev.bombinating.jooq-codegen`

Plugin Id

dev.bombinating.jooq-codegen

Current Plugin Owner

Maybe bombinating-dev

Context

See https://discuss.gradle.org/t/delete-unused-version-2-0-of-dev-bombinating-jooq-codegen/33561

Update publish plugin to expose an API for using pre-existing pom file

Expected Behavior

When wanting to publish an already built gradle plugin artifact in the Plugin portal, you want to use the existing pom file. See #9 (comment).

The pluginBundle DSL should provide a way to use the existing pom file (either as a supplied file or as the pom resource in the artifact jar) rather than always generating a new pom file.

Current Behavior

The publish plugin always generates a new pom file which will not contain necessary information already in the existing pom file.

Context

See #9.

Transfer ownership of `de.europace` namespace to `europace` user

Plugin Id

https://plugins.gradle.org/search?term=de.europace

Current Plugin Owner

gesellix

Expected Plugin Owner

europace

Context

See https://discuss.gradle.org/t/transfer-plugin-ownership-published-with-wrong-user/33535

Approval required for de.chkpnt.truststorebuilder

Expected Behavior

As far as I understood the publish-plugin, a manual approval by the Gradle team shouldn't be needed if the group ID isn't overwritten.

Current Behavior

An approval is required for v0.4.0 of my Gradle plugin de.chkpnt.truststorebuilder. Unfortunately, I do not remember if the previous versions needed an approval, too, or if it is a new behaviour.

Context

I'm using the groupId de.chkpnt and artifactId truststorebuilder-gradle-plugin.

Steps to Reproduce

The plugin has been published via the publish-plugin on Travis-CI. See lines 580-587 in the corresponding build log.

Your Environment

chkpnt/truststorebuilder-gradle-plugin@ab351ba

Add robot account as contributor

Hello,

Plugin Id

• com.neo4j.gradle.asciidoctor.AsciidoctorModuleDescriptorPlugin
• com.neo4j.gradle.s3.S3Plugin
• com.neo4j.gradle.wordpress.WordPressPlugin

Current Plugin Owner

Me (https://plugins.gradle.org/u/ggrossetie)

Expected Plugin Owner

Our non-human friend: https://plugins.gradle.org/u/neo4j-oss-build

Context

We've created a 🤖 account to publish releases on the Gradle plugins portal and as a result we would like to add https://plugins.gradle.org/u/neo4j-oss-build as a contributor.

Sync with JCenter seems to be broken

Expected Behavior

My newest version, 0.3, is shown in the plugin portal along with the new plugins.

Current Behavior

My latest plugin version, 0.3, is not shown in the plugin portal along with the new plugins (dev.nokee.objective-c-ios-application and dev.nokee.objective-c-xctest-test-suite).

Context

One noteworthy comment is the attributes were set after the artifacts were pushed to Bintray.

Steps to Reproduce

Not too sure, I would say publish to Bintray into a repository that is already synced with the plugin portal and tag the attributes required by the portal after?

Your Environment

Transfer plugin com.widen.versioning to widen

Plugin Id

com.widen.versioning

Current Plugin Owner

sagebind (me)

Expected Plugin Owner

widen (@widendev on GitHub)

Context

I created this plugin on behalf of Widen Enterprises as an employee. Now the Widen development team has a dedicated account on the Plugin Portal for publishing such plugins, so I'd like to transfer ownership from my personal account to the "official" Widen account.

Automatically suggest related plugins

When looking at a specific plugin, suggest "More Like This" (related) plugins to allow users to explore more.

Expected Behavior

On an individual plugin page, related plugins should be displayed.

Current Behavior

No such functionality exists.

Context

Often when I am looking for a plugin, I would like to find out about the alternatives available. For instance, if I am looking for a specific Cucumber plugin, I would like to find out what others are available that could achieve the same task.

Issue with synchronizing plugins published on Bintray

There is an issue with plugin published on Bintray the Gradle team is looking into. This issue is simply a placeholder for any discussion or status on the issue. We believe to be the source of the following issues:

• #23 (https://discuss.gradle.org/t/syncing-a-new-plugin-from-bintray/32184)
• #20
• #9

DO NOT APPROVE certain plugins that are pending approval

please DO NOT APPROVE certain plugin versions that are pending approval.
please DELETE those versions instead. i'll have to republish them.

Plugin Id

all of com.github.lanchon.dexpatcher.*

specifically:

• com.github.lanchon.dexpatcher.apk-library
• com.github.lanchon.dexpatcher.base
• com.github.lanchon.dexpatcher.patched-application
• com.github.lanchon.dexpatcher.patch-library

ONLY DELETE VERSIONS 2.1.0 of these, which are still pending approval.

Current Plugin Owner

i am

Context

what else do you need?

Show VCS url on the plugin page

Expected Behavior

Show the VCS URL configured for each published plugins. When the url is configured like the following:

It should show on the plugin page.

Current Behavior

The plugin page doesn't show the VCS URL making it harder to find the source code that was used to build the plugin:

Context

See https://github.com/gradle-guides/gradle-guides-plugin/issues/55

Specified tags are omitted from the published plugin's portal page

Expected Behavior

I expected that all tags listed in my plugin's publishing metadata would appear on the plugin's portal page.

Current Behavior

An unlucky number of only thirteen of the tags I specified in the metadata appear on the plugin's portal page.

Context

The Configure the Plugin Publishing Plugin section of the user guide talks about tags. The How do I use the Plugin Publishing Plugin? also talks about tags. Neither of those documents define any specific limit on the number of tags that can be used.

The pluginBundle block of the build script I use to publish the com.lingocoder.mrjar plugin lists twenty-two tags. Each tag represents the capabilities mrJar provides. The intent is to make it easier for users to find the capabilities they would be looking for.

In the absence of any explicitly-defined limit to the number of tags allowed — nor any publicly-defined character limit — it's reasonable to expect that all the publishing metadata I specify, would be used.

How has this issue affected you?

The original content of the Building Java 9 Modules section of the user guide has recently been removed. In its place is a tag-filtering, query-stringed link that refers readers to the plugin portal. Because the tag that that search query uses, is one of the tags that was omitted from my plugin's published metadata, users looking for the JPMS capability that my plugin provides, will not see mrJar on the page that the user guide refers them to.

Steps to Reproduce

1. Visit the Building Java 9 Modules section of the user guide
2. Click on the „Some community plugins“ referral link...
3. Note that the results that listed are incomplete.

Your Environment

N.A.

Add organization accounts

Can we have "organization" accounts, similar to github organizations that could maintain a list of developers with:

• read access (consult the list of plugins)
• write access (upload plugins, might be merged with read access ?)
• admin access (add/manage users)

This would allow to manage several contributors in a more flexible way than sharing an email + password.

Two different descriptions are displayed — And old one and a recently updated one

The com.lingocoder.mr v0.0.16 plugin displays two different descriptions. One is correct and should be displayed wherever a description is needed:

• „Adds easy JPMS module creation capabilities to Gradle. Enhances Buildship/Eclipse with JPMS modularity. Easy Multi-Release JAR File assembly“

---

---

The other one is outdated and should have been replaced by the more recently-published one above:

• „A Gradle plugin that supports compiling, testing, assembling and maintaining Multi-Release JAR Files“

---

---

Expected Behavior

I expected that the description that I specified in the build script that published the plugin to be displayed wherever the portal displays descriptions

Current Behavior

On the main portal landing page and on search result pages, the portal displays an old outdated description.

Context

I would like people who come upon my plugin in search results to see the correct, more currently-appropriate description of the plugin.

Steps to Reproduce

1. Visit the portal landing page

2. In the search box, enter „jpms“

   • com.lingocoder.mrjar appears in the results.

3. Observe that the description displays the above outdated text.

4. Click on the com.lingocoder.mrjar search result link.

5. Observe that on the plugin's page, a different description (the correct one) is displayed.

Your Environment

Not applicable.

Transfer ownership of plugin 'com.gemnasium.gradle-plugin' to user 'ifrenkel'

Plugin Id

com.gemnasium.gradle-plugin

Current Plugin Owner

StFS

Expected Plugin Owner

ifrenkel

Context

I created a Gradle plugin to generate a dependency report that could be used by Gemnasium for a dependency security scan. This is used in GitLab and my intention was to help things along by creating the initial version of the plugin. Now, the guys at GitLab are ready to receive ownership of the code and the publishing mechanism. The user 'ifrenkel' will be the one handling this on their behalf.

Here is a link to the issue keeping track of this in GitLab:
https://gitlab.com/gitlab-org/gitlab/issues/13075

Unable to publish `org.kordamp.gradle.clirr` version 0.30.0 and following path versions

Expected Behavior

Should work

Current Behavior

Failing to publish

Context

See #20

Steps to Reproduce

Your Environment

Transfer ownership for org.jetbrains.kotlinx.knit plugin to kotlin

Plugin Id

org.jetbrains.kotlinx.knit

Current Plugin Owner

elizarov

Expected Plugin Owner

kotlin

Context

I've been testing plugin publishing from my own account. After completing the testing I've deleted the plugin and I don't see it on my account page anymore. However, kotlin account cannot still upload it. The sources for the plugin (authored by me) are here: https://github.com/Kotlin/kotlinx-knit/blob/master/build.gradle.kts#L70-L80

Adjust plugin descriptions and tags for `dev.nokee.*` plugins

There seems to be no way to edit the description and tags for a plugin synched via Bintray. I would like to change the description, tag and website as follow:

dev.nokee.cpp-language

Description: Provides C++ language compilation to Nokee plugins; see the documentation to learn more.
Tags: gradle-native, native, cpp, c++, nokee
Website: https://nokee.dev/docs/cpp-language-plugin

dev.nokee.c-language

Description: Provides C language compilation to Nokee plugins; see the documentation to learn more.
Tags: gradle-native, native, c, nokee
Website: https://nokee.dev/docs/c-language-plugin

dev.nokee.objective-cpp-language

Description: Provides Objective-C++ language compilation to Nokee plugins; see the documentation to learn more.
Tags: gradle-native, native, objective-cpp, objcpp, objective-c++, nokee
Website: https://nokee.dev/docs/objective-cpp-language-plugin

dev.nokee.objective-c-language

Description: Provides Objective-C language compilation to Nokee plugins; see the documentation to learn more.
Tags: gradle-native, native, objective-c, objc, nokee
Website: https://nokee.dev/docs/objective-c-language-plugin

dev.nokee.jni-library

Description: Provides support for building Java Native Interface (JNI) libraries supporting Gradle core features; see the documentation to learn more.
Tags: jni, gradle-native, native, cpp, objective-c, objective-cpp, c, nokee
Website: https://nokee.dev/docs/jni-library-plugin

Ownership transfer of com.google.protobuf

Plugin Id

com.google.protobuf

Current Plugin Owner

zhangkun83

Expected Plugin Owner

voidzcy (both the Plugin Portal username and Github username)

Context

@voidzcy is already the maintainer on the github project: https://github.com/google/protobuf-gradle-plugin

Provide download counts and stats

Provide download counts and stats for a better understanding of the plugins in the portal.

Expected Behavior

Plugins in the portal should show how many times it has been downloaded over time and any other useful stats.

Current Behavior

Currently, download stats are missing from plugins in the plugin portal.

Context

Without the download counts and stats, it is difficult to know if we are dealing with a mature plugin, an up to date one, an outdated one or a brand new one which not many are using.

Plugin delete request: com.hiberbee.ansible

Plugin IDs:

• com.hiberbee.ansible

Owner:

• me @vladyslavvolkov

Context:
This is duplicate of my plugin with different id.

Publication to plugin portal failed for `org.kordamp.gradle.jandex`

Publishing version 0.2.0 of the jandex-gradle-plugin failed with a weird error stating that the given version was already published (which it wasn't).

Expected Behavior

Successful publication to the Gradle Plugin portal.

Current Behavior

Publication failed with

Publishing plugin org.kordamp.gradle.jandex version 0.2.0

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publishPlugins'.
> Failed to post to server.
  Server responded with:
  Plugin: 'org.kordamp.gradle.jandex', version: '0.2.0' exists already. It was created: 2019-11-26 11:34:38.333

Context

Attempted to release version 0.2.0 of this plugin.

Steps to Reproduce

It'd be tricky to reproduce on production as version 0.2.0 indeed appears top exists after the fact. Perhaps it can be reproduced on a staging environment. Checkout https://github.com/aalmiray/jandex-gradle-plugin and publish tags 0.1.0 and 0.2.0.

Your Environment

---

Gradle 6.0.1

Build time: 2019-11-18 20:25:01 UTC
Revision: fad121066a68c4701acd362daf4287a7c309a0f5

Kotlin: 1.3.50
Groovy: 2.5.8
Ant: Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM: 1.8.0_191 (Oracle Corporation 25.191-b12)
OS: Mac OS X 10.14.4 x86_64

Gradle Plugin Portal doesn't keep DSL choice after page reload

New DSL switcher on Gradle Plugin Portal doesn't keep user's choice about DSL.
But for example, Gradle docs support this and remember preferred DSL language

1. Open a page of any plugin on Gradle Plugin Portal, for example this one:
   https://plugins.gradle.org/plugin/com.github.johnrengelman.plugin-shadow
2. Select "Kotlin" tab to switch DSL language
3. Reload page or open any other plugins' page

Expected Behavior

"Kotlin" tab should be active, Kotlin DSL snippet should be visible

Current Behavior

"Groovy" tab will be active

Remove plugin org.podval.docbook-gradle-plugin

Plugin Id

org.podval.docbook-gradle-plugin

Current Plugin Owner

• Leonid Dubinsky
• Gradle Plugin Portal: dub
• GitHub: dubinsky

Context

Plugin moved to org.opentorah.docbook.

Wrong Gravatar usage on plugins.gradle.org

I'm not sure whether this is the appropriate place to report this, so sorry if not.
https://plugins.gradle.org/u/Vampire does not show my assigned Gravatar.
This is caused by not following the rules described at https://de.gravatar.com/site/implement/hash/.
Specifically, the generated hash is from the e-mail address as-is instead of lowercased.
The used hash is 2ea6fcba24a569da6b4b546f9a62917d which is the hash of [email protected], but the hashing algorithm should first lower-case the address to [email protected] before the hash is calculated.

Transfer ownership of plugin `no.skatteetaten.gradle.aurora` to `Skatteetaten`

Plugin Id

https://plugins.gradle.org/plugin/no.skatteetaten.gradle.aurora

Current Plugin Owner

Unknown

Expected Plugin Owner

Skatteetaten

Context

See https://discuss.gradle.org/t/transfer-plugin-ownership-skatteetaten/33706