Agree, even a minimal placeholder would do it, perhaps show security warnings and deprecation message (whatever is available).

Right now the experience if you're already using a plugin is reasonable inside Jenkins, but not on the plugin site.

Hello, may I work on this issue? I'm actually new to Jenkins, would really be obliged if anyone can guide me. As far I can understand from the description I need to change the UX for the use for the deprecated plugins. Maybe show some message or warning when they redirect to the link that this plugin is deprecated. Correct me if I'm wrong in anyway.

Poking Gavin Mogan  in case he's interested.

I recently thought about this problem (IIRC triggered by James Nord ) and we probably "just" need to add a new update site variant to https://github.com/jenkins-infra/update-center2/ which uses a different, much shorter list of ignored plugins, and consume that as the update center metadata URL on plugins.jenkins.io.

Add a new label to everything only available there ("removed"?), then render that label on plugins.jenkins.io like the existing deprecation label, just stronger.

> Hello, may I work on this issue? I'm actually new to Jenkins, would really be obliged if anyone can guide me. As far I can understand from the description I need to change the UX for the use for the deprecated plugins. Maybe show some message or warning when they redirect to the link that this plugin is deprecated. Correct me if I'm wrong in anyway.

Always happy to have more help on the issue.

The issue is bigger than it sounds though. Right now, since plugin site is using update-center as its source of truth, when update-center stops returning plugins that have been removed, then plugin-site won't have any info on it. The plugin site should get a 404 handler, but handling removed plugins as it stands right now isn't really an option.

I personally rather see removed plugins have labels and jenkins core filters out removed ones, so they can still get security warnings and stuff. But a secondary list of removed plugins would also work and be pretty easy I think (from plugin-site side).

I was going through the codebase of the plugin-site and the update-center, trying to understand how this works out. And the plugin-site is showing results for those which are only labeled deprecated but not archived, like the violations-plugin but in the case of pmd-plugin it can't process the url of that plugin as it is no longer available in a non-archived manner. So keeping an updated list of archived or removed plugins which can be consumed by plugin-site could resolve this issue. Since, update-center as it is now may does not look into the archived repositories that needs to be handled. 

Agree w Gavin Mogan, "The issue is bigger than it sounds though." I titled this - UX as User eXperience, but that's only part of the problem. Daniel Beck's suggestion of a new update site seems onerous, tho. I am only vaguely familiar with the inner workings of Update Center or pluginManager; some thoughts..

The case of pmd plugin is perhaps a "best-case scenario". (my take) The developer found his plugin's functionality has been entirely superseded by another plugin, decided to deprecate it, voluntarily marked it as such and provided clear instructions in the source README on how to proceed. They did "all the right things".

The problem is those instructions are not passed along to the user via the Update Center or pluginManager UI; it's just gone 403 to the user. A regular user of Jenkins may not know how to get to the Github repo to investigate this or discover the alternate locations to manually download and install as a workaround, at least until the repo disappears too.

It is possible this can be overcome procedurally in some form. Perhaps a new release is made with an empty package so the entry remains but is useless to install. This is perhaps the easiest case to tackle. A new class of tag [ Deprecated/Decommissioned/Unsupported ] could be of use too.

The second case I am familiar with is the tfs-plugin. In this case, the plugin has a security vulnerability ( SECURITY-1506 / CVE-2020-2249 ) which was not addressed by the maintainers, but was actually removed by Jenkins maintainers as it does not meet the OSI open source license requirements - INFRA-2751. In this case, there's no indication in the Update Center/ pluginManager why it's no longer available AND there's no indication in GitHub there's anything wrong by policy or vulnerability.

In the case of tfs-plugin (where using tfvc), the user is not presented any alternatives to the plugin. A lack of SCM step effectively renders Jenkins useless for its intended purpose (ps: a poor a workaround is to use the `tf ` cmd line), resulting in a poor UX and reputation for Jenkins, not Microsoft. Lesser impairments perhaps for buildstep/wrapper plugins.

I suppose there's another scenario where Jenkins maintainers pull a plugin not for a license violation by rather the plugin contains an egregiously dangerous vulnerability (eg: malware, bitminer, etc.). Then what? It remains available and undocumented in the jenkinsci GitHub.

I'm sure the Jenkins maintainers are aware of additional scenarios.

In the latter two scenarios, again is it possible to overcome this procedurally? Would it possible to show the plugin entry in the Update Center / pluginManager, with a banner similar to UNAVAILABLE / Adopt a Plugin, linking to the Security Advisory that forced the withdrawal of plugin while retaining the entry (and maybe restricting the download) ? That would not involve any cooperation on the developer's part, though the repo would remain without warning. The banner could be a useful mechanism to warn existing plugin users of the license violation (which may impact their continued use).

I personally rather see removed plugins have labels and jenkins core filters out removed ones, so they can still get security warnings and stuff. But a secondary list of removed plugins would also work and be pretty easy I think (from plugin-site side).

Security warnings and deprecation warnings are already served separately, which allows Jenkins to show these even for plugins no longer distributed, so this doesn't apply.

Note that all the changes to the plugin site needed in my proposal would be to point to a different JSON file. Obviously it would be good to indicate a plugin is no longer being distributed, or we're just replacing one cause for confusion ("Why is this mentioned somewhere but not on the plugin site?") for another ("Why is this listed on the plugin site but not accessible in Jenkins?").

The problem is those instructions are not passed along to the user via the Update Center or pluginManager UI; it's just gone 403 to the user.

If you have it installed, Jenkins will tell you. It's just not available for installation.

https://github.com/jenkins-infra/update-center2/blob/55f6a4370e090b25cf359c0773a60c1939e8253f/resources/deprecations.properties#L129 creates a deprecation notice with a link to the issue. There could be better docs but by the time we did this it had been deprecated in docs for well over a year.

In this case, there's no indication in the Update Center/ pluginManager why it's no longer available AND there's no indication in GitHub there's anything wrong by policy or vulnerability.

Good point. At the time we removed it, I hoped it would be temporary, so didn't add a label that would inform existing users. This is a simple oversight that can easily be addressed with a PR to update-center2.

The banner could be a useful mechanism to warn existing plugin users of the license violation (which may impact their continued use).

As above, we have ways to inform existing users, it's just new users (and that includes renewed users, e.g. in ephemeral Jenkins setups) that have a harder time figuring out what happened. As deprecation metadata is served through the usual means, this is an RFE to whatever the plugin management tool of choice is.

a banner similar to UNAVAILABLE

Possible by iterating over over each entry in deprecations/security warnings and creating placeholders for the plugin IDs, but the code underlying the update center is a bit of a mess, plus we don't have any metadata right now other than plugin ID. Additionally we've had plenty negative feedback to "UNAVAILABLE", indicating it's confusing, so I'm not sure this is a great choice.

TBH with the plugin site showing placeholders for plugins that are no longer being distributed, I'm not sure we need a solution inside Jenkins. I Would hold that off for a bit.