是否有一种自动化方式来确定或查找图书馆的生命周期终止 (EOL)/支持终止 (EOS) 通知？
这背后的具体背景：
我们的软件使用大约 50 多个库以及一些平台。我似乎找不到一个自动解决方案，它可以告诉您特定库是否已终止支持。
我目前遇到的解决方案是黑鸭。我的理解（仅使用 Code Center 后）是 Black Duck 更关心 OSS 治理，不包括专有软件。 Black Duck 确实会通知用户有关安全更新和许可证冲突的信息，但据我所知，它并没有通知用户 EOL/EOS。
我们目前的解决方法是执行以下操作：
列出我们使用的所有库（我们使用 Artifactory 执行此操作） 定期检查图书馆网站是否有任何通知 然后以某种形式维护它（目前是一个 wiki 页面，这是一场噩梦） 出于术语目的：
一个 jar 或 npm 模块的库
【问题讨论】：
标签： maven-3
我认为目前没有比您的解决方法更好的解决方案。
Maven Central / Sonartype 不提供更新先前上传工件的 POM 文件的方法。因此，发布工件的人无法对其进行更新以说它已被弃用或报废或……其他任何事情。 （工件是不可变的确实有很好的理由。）
Maven Central / Sonartype 或任何第 3 方均未维护已弃用或报废工件的注册表。
那么……这样的事情可能吗？
技术上是的。上传到 Maven Central 的所有工件都必须具有带有已发布 PGP 公钥的 PGP 签名。因此，第三方站点可以检查 EOL 通知是否使用与用于签署已发布工件的密钥对相同的密钥对进行签名。然后他们可以创建一个数据库，其中包含一个用于查询工件状态的 Web API，以及一个 Maven 插件来完成这项工作。 （可能会有一些有趣的缩放问题......但没有什么是无法解决的。）
在实践中，需要说服足够多的开发人员（工件的消费者）相信自动检查 EOL 工件是一个好主意，并说服足够多的供应商（工件供应商）发布 EOL 通知是一个好主意。并且需要有人掏钱来支付登记处的基础设施以及建造和运行登记处的人员。
鉴于最近发生的事件（例如 log4shell 和相关漏洞），它可能真的会发生。
【讨论】：