akka-core 依赖安全治理artifact-bom 目录与 sbt-artifact-bom 插件生成 Maven BOM 的工程实践解析【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址: https://gitcode.com/gh_mirrors/ak/akka-core本文围绕 akka-core 仓库中artifact-bom目录及其说明文档展开讲解 Akka 项目如何利用sbt-artifact-bom插件在compile阶段自动为每个模块生成 Maven 依赖清单BOM描述符并将其纳入 PR 提交流程、交由 Wiz 等安全扫描工具消费。读完本文你将掌握这套构建期自动生成 → 随 PR 提交 → 安全工具扫描的依赖可见性治理链路并理解生成产物pom.xml的完整结构、插件接入方式与各模块覆盖范围。artifact-bom 目录是什么在 akka-core 仓库根目录下存在一个名为 artifact-bom 的目录其说明文档 artifact-bom/README.md 明确指出The Maven dependency descriptors in theartifact-bomdirectory support our security tooling.也就是说artifact-bom目录中存放的是面向 Maven 生态的依赖描述符dependency descriptors它们不是用来发布或构建 Akka 的常规构建产物而是专门服务于项目的安全工具链。这种以机器可读方式集中记录每个模块全部直接依赖及其精确版本的清单在软件供应链安全领域通常被称为 BOMBill of Materials物料清单。从仓库目录结构看artifact-bom下为每个启用了该能力的 Akka 模块各建一个子目录例如artifact-bom/akka-actor/核心 Actor 模块artifact-bom/akka-stream/流处理模块artifact-bom/akka-cluster-sharding/集群分片模块artifact-bom/akka-persistence/ 及akka-persistence-query、akka-persistence-typed、akka-persistence-tck等持久化系列artifact-bom/akka-remote/、artifact-bom/akka-cluster/、artifact-bom/akka-discovery/ 等分布式模块artifact-bom/akka-testkit/、artifact-bom/akka-slf4j/、artifact-bom/akka-pki/ 等支撑模块每个子目录内都是一个生成好的pom.xml文件即该模块对应的 Maven BOM 描述符。生成机制sbt-artifact-bom 插件artifact-bom下的文件不是手写的而是通过sbt-artifact-bom 插件在 sbt 构建过程中显式激活后自动生成的。原文档的原话是These are generated by explicit activation of the sbt-artifact-bom plugin on the sbt projects.也就是说只有显式启用了该插件的 sbt 项目才会产出对应的 BOM 描述符仓库中有三处关键配置共同构成了这一机制。1. 在 plugins.sbt 中声明插件project/plugins.sbt 中以addSbtPlugin方式引入了插件注释也明确说明其用途是create pom.xml for scanning tools为扫描工具创建 pom.xml// create pom.xml for scanning tools addSbtPlugin(io.akka.sbt % sbt-artifact-bom % 0.2.0)2. 在 build.sbt 中为各模块启用插件仓库根目录的 build.sbt 中每个需要生成 BOM 的模块定义都通过.enablePlugins(ArtifactBomPlugin)显式激活该插件。例如 actor 模块的定义lazy val actor akkaModule(akka-actor) .settings(Dependencies.actor) .settings(AutomaticModuleName.settings(akka.actor)) .settings(Compile / unmanagedSourceDirectories { val ver scalaVersion.value.take(4) (Compile / scalaSource).value.getParentFile / sscala-$ver }) .settings(VersionGenerator.settings) .enablePlugins(BoilerplatePlugin) .enablePlugins(ArtifactBomPlugin)从仓库全局搜索可以看出build.sbt中enablePlugins(ArtifactBomPlugin)出现在 actor、stream、cluster、cluster-sharding、persistence、remote、discovery、distributed-data 等二十余个模块定义上与artifact-bom目录下的模块子目录一一对应——这正是explicit activation显式激活语义的体现不启用插件的模块不会出现在 BOM 目录中。3. 在 AkkaBuild.scala 中配置 BOM 行为project/AkkaBuild.scala 首先导入了插件的自动导入项import io.akka.sbt.ArtifactBomPlugin.autoImport.makeBomIncludeDependencies随后在 项目级设置 中开启ThisBuild / makeBomIncludeDependencies : true,从设置项名称可以推断makeBomIncludeDependencies控制生成的 BOM 描述符中是否包含依赖项dependencies清单当前仓库将其在ThisBuild级别统一置为true即所有启用插件的模块生成的文件都会列出各自的实际依赖。而各模块依赖的版本定义集中在 project/Dependencies.scala 中统一维护例如scala213Version 2.13.17、reactiveStreamsVersion 1.0.4、jacksonCoreVersion 2.18.8等这些常量最终会被 sbt 解析为生成文件中的具体版本号。生成时机与 PR 工作流原文档对生成时机与提交流程给出了明确的工程约定File generation runs oncompile. It should be enough to add those generated files to the PR when changing the dependencies.这句话包含两层关键信息生成时机绑定compile任务只要执行 sbt 的compile插件就会重新生成对应的pom.xml。也就是说BOM 文件始终与当前依赖定义保持同步无需单独的额外命令或手工维护步骤。依赖变更时随 PR 提交当开发者修改了依赖例如在 project/Dependencies.scala 中升级某个库的版本本地编译后artifact-bom下相关模块的pom.xml会自动更新此时开发者只需把这些重新生成的文件一并加入同一个 PR就能保证代码变更与依赖清单变更同时被审查、同时入库。这是一条非常轻量的流程不要求开发者理解 BOM 的细节也不要求在 CI 中单独执行发布步骤只要遵循改依赖 → compile → 提交生成文件的习惯即可。从文档措辞should be enough只需这样做就够了可以看出这是项目刻意压低维护成本的设计取向。生成文件的结构深度解析为了让安全工具能够准确解析生成的pom.xml遵循标准的 Maven POM 4.0.0 格式。下面以几个实际生成的文件为例说明其结构。最小形态akka-actorartifact-bom/akka-actor/pom.xml 是结构最简单的例子project xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdcom.typesafe.akka/groupId artifactIdakka-actor/artifactId version100.0.0/version packagingpom/packaging dependencyManagement dependencies dependency groupIdcom.typesafe/groupId artifactIdconfig/artifactId version1.4.8/version /dependency dependency groupIdorg.scala-lang/groupId artifactIdscala-library/artifactId version2.13.17/version /dependency /dependencies /dependencyManagement dependencies dependency groupIdcom.typesafe/groupId artifactIdconfig/artifactId version1.4.8/version /dependency dependency groupIdorg.scala-lang/groupId artifactIdscala-library/artifactId version2.13.17/version /dependency /dependencies /project从中可以解读出几个关键设计packagingpom/packaging表明该文件是纯描述符不产生任何可执行或可打包的构建产物仅用于向工具暴露依赖信息。dependencyManagement以 Maven 的标准依赖版本管理语义锁定每个依赖的groupId、artifactId与精确version。顶层dependencies重复列出同样的依赖项。从仓库的生成结果看两部分内容保持一致这可以让只解析dependencies节点的扫描工具也能直接拿到完整清单。版本号完全对齐仓库依赖定义config 1.4.8、scala-library 2.13.17均可在 project/Dependencies.scala 中找到对应常量印证了生成文件与依赖定义实时同步的机制。version标签当前仓库生成文件的模块版本为100.0.0这是仓库自身的版本号可能为仓库快照期的占位版本实际内容以当前仓库文件为准。多依赖形态akka-streamartifact-bom/akka-stream/pom.xml 展示了带多个依赖的模块形态它在config、scala-library之外还锁定了流编程规范库dependency groupIdorg.reactivestreams/groupId artifactIdreactive-streams/artifactId version1.0.4/version /dependencyreactive-streams 1.0.4同样与 project/Dependencies.scala 中val reactiveStreamsVersion 1.0.4完全一致。复杂形态akka-cluster-shardingartifact-bom/akka-cluster-sharding/pom.xml 是依赖最丰富的例子之一其dependencyManagement中锁定了十余个依赖涵盖本地调用与原生接口绑定com.github.jnr:jffi、jnr-ffi、jnr-constants、jnr-a64asm、jnr-x86asm如 1.3.13、2.2.17 等版本ASN.1 编解码com.hierynomus:asn-one0.6.0配置库com.typesafe:config1.4.8高性能数据结构与内存映射库org.agrona:agrona1.22.0、org.lmdbjava:lmdbjava0.9.1字节码操作org.ow2.asm:asm系列asm、asm-analysis、asm-commons、asm-tree、asm-util均为 9.7.1响应式流规范与日志门面org.reactivestreams:reactive-streams1.0.4、org.slf4j:slf4j-api2.0.18Scala 标准库org.scala-lang:scala-library2.13.17这些依赖版本与 project/Dependencies.scala 中的agronaVersion 1.22.0、slf4jVersion 2.0.18等常量一一对应可见 BOM 生成是集中式依赖定义向机器可读描述符的自动映射。轻量形态akka-persistence-sharedartifact-bom/akka-persistence-shared/pom.xml 则只依赖scala-library一个库说明 BOM 的内容完全由模块自身的真实依赖决定不掺入任何多余条目。安全扫描对接Wiz 与软件供应链治理原文档明确了生成文件的下游消费者The generated file is then scanned by Wiz.即这些pom.xml生成后会被Wiz安全平台扫描。从文档上下文support our security tooling、scanned by Wiz以及文档中附带的 Wiz 项目状态页面可以看出这套机制的典型工作方式是每个 Akka 模块在compile时自动生成精确到版本的 Maven 依赖清单开发者修改依赖后把重新生成的 BOM 文件随 PR 提交使仓库中的清单始终反映最新依赖状态Wiz 等安全工具扫描这些 BOM 描述符将清单中的组件与已知漏洞数据库进行比对从而在依赖引入的第一时间暴露存在已知 CVE 风险的组件版本。这种做法的核心价值在于依赖可见性Akka 是一个横跨 actor、stream、cluster、persistence、remote 等数十个模块的大型多模块项目各模块的依赖规模和类型差异巨大从单个scala-library到 cluster-sharding 的十余个依赖。若依赖信息只散落在 sbt 的build.sbt、project/Dependencies.scala与各模块配置中安全工具将难以统一、稳定地解析而通过构建期自动生成的标准化 Maven POM工具获得了一份开箱即用的精确物料清单无需理解 sbt 的 DSL 语法即可完成组件分析。需要说明的是本文对 Wiz 扫描工作方式的具体细节扫描触发方式、漏洞库对接、报告展示等属于从文档与目录结构推断的合理理解仓库本身只确认了生成 → 提交 → 由 Wiz 扫描这一链路。模块覆盖范围一览从仓库实际目录看artifact-bom目前覆盖了以下模块对应 artifact-bom 下的子目录Actor 与测试akka-actor、akka-actor-typed、akka-actor-testkit-typed、akka-testkit、akka-stream-testkit流处理akka-stream、akka-stream-typed集群与分布式akka-cluster、akka-cluster-typed、akka-cluster-metrics、akka-cluster-sharding、akka-cluster-sharding-typed、akka-cluster-tools、akka-remote、akka-multi-node-testkit、akka-coordination、akka-discovery持久化akka-persistence、akka-persistence-typed、akka-persistence-query、akka-persistence-shared、akka-persistence-tck、akka-persistence-testkit、akka-distributed-data基础设施与集成akka-protobuf-v3、akka-serialization-jackson、akka-slf4j、akka-pki这些模块的生成结果与 build.sbt 中enablePlugins(ArtifactBomPlugin)的分布相互印证。若未来新增模块需要纳入安全扫描范围只需在模块定义上追加一行.enablePlugins(ArtifactBomPlugin)并在compile后提交新生成的pom.xml即可。小结一套低成本的依赖安全基线akka-core 的artifact-bom机制给出了一条清晰的工程范式用构建期自动生成 PR 随变更提交的方式为安全扫描工具持续提供精确、标准、始终新鲜的依赖清单。它不要求开发者手工维护 XML不增加 CI 的额外负担只通过 sbt 插件在compile阶段的自动输出就把依赖定义这一单一事实源同步为安全工具可消费的 Maven 描述符。对于任何希望在大型多模块项目中落地软件供应链安全扫描的团队这套插件生成 → 文件入库 → 工具扫描的组合都是值得参考的轻量级实践。若想深入验证或复现可以直接阅读仓库中的 artifact-bom/README.md、project/plugins.sbt、project/AkkaBuild.scala、build.sbt 以及 artifact-bom 目录下各模块的pom.xml文件。【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址: https://gitcode.com/gh_mirrors/ak/akka-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
akka-core 依赖安全治理artifact-bom 目录与 sbt-artifact-bom 插件生成 Maven BOM 的工程实践解析【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址: https://gitcode.com/gh_mirrors/ak/akka-core本文围绕 akka-core 仓库中artifact-bom目录及其说明文档展开讲解 Akka 项目如何利用sbt-artifact-bom插件在compile阶段自动为每个模块生成 Maven 依赖清单BOM描述符并将其纳入 PR 提交流程、交由 Wiz 等安全扫描工具消费。读完本文你将掌握这套构建期自动生成 → 随 PR 提交 → 安全工具扫描的依赖可见性治理链路并理解生成产物pom.xml的完整结构、插件接入方式与各模块覆盖范围。artifact-bom 目录是什么在 akka-core 仓库根目录下存在一个名为 artifact-bom 的目录其说明文档 artifact-bom/README.md 明确指出The Maven dependency descriptors in theartifact-bomdirectory support our security tooling.也就是说artifact-bom目录中存放的是面向 Maven 生态的依赖描述符dependency descriptors它们不是用来发布或构建 Akka 的常规构建产物而是专门服务于项目的安全工具链。这种以机器可读方式集中记录每个模块全部直接依赖及其精确版本的清单在软件供应链安全领域通常被称为 BOMBill of Materials物料清单。从仓库目录结构看artifact-bom下为每个启用了该能力的 Akka 模块各建一个子目录例如artifact-bom/akka-actor/核心 Actor 模块artifact-bom/akka-stream/流处理模块artifact-bom/akka-cluster-sharding/集群分片模块artifact-bom/akka-persistence/ 及akka-persistence-query、akka-persistence-typed、akka-persistence-tck等持久化系列artifact-bom/akka-remote/、artifact-bom/akka-cluster/、artifact-bom/akka-discovery/ 等分布式模块artifact-bom/akka-testkit/、artifact-bom/akka-slf4j/、artifact-bom/akka-pki/ 等支撑模块每个子目录内都是一个生成好的pom.xml文件即该模块对应的 Maven BOM 描述符。生成机制sbt-artifact-bom 插件artifact-bom下的文件不是手写的而是通过sbt-artifact-bom 插件在 sbt 构建过程中显式激活后自动生成的。原文档的原话是These are generated by explicit activation of the sbt-artifact-bom plugin on the sbt projects.也就是说只有显式启用了该插件的 sbt 项目才会产出对应的 BOM 描述符仓库中有三处关键配置共同构成了这一机制。1. 在 plugins.sbt 中声明插件project/plugins.sbt 中以addSbtPlugin方式引入了插件注释也明确说明其用途是create pom.xml for scanning tools为扫描工具创建 pom.xml// create pom.xml for scanning tools addSbtPlugin(io.akka.sbt % sbt-artifact-bom % 0.2.0)2. 在 build.sbt 中为各模块启用插件仓库根目录的 build.sbt 中每个需要生成 BOM 的模块定义都通过.enablePlugins(ArtifactBomPlugin)显式激活该插件。例如 actor 模块的定义lazy val actor akkaModule(akka-actor) .settings(Dependencies.actor) .settings(AutomaticModuleName.settings(akka.actor)) .settings(Compile / unmanagedSourceDirectories { val ver scalaVersion.value.take(4) (Compile / scalaSource).value.getParentFile / sscala-$ver }) .settings(VersionGenerator.settings) .enablePlugins(BoilerplatePlugin) .enablePlugins(ArtifactBomPlugin)从仓库全局搜索可以看出build.sbt中enablePlugins(ArtifactBomPlugin)出现在 actor、stream、cluster、cluster-sharding、persistence、remote、discovery、distributed-data 等二十余个模块定义上与artifact-bom目录下的模块子目录一一对应——这正是explicit activation显式激活语义的体现不启用插件的模块不会出现在 BOM 目录中。3. 在 AkkaBuild.scala 中配置 BOM 行为project/AkkaBuild.scala 首先导入了插件的自动导入项import io.akka.sbt.ArtifactBomPlugin.autoImport.makeBomIncludeDependencies随后在 项目级设置 中开启ThisBuild / makeBomIncludeDependencies : true,从设置项名称可以推断makeBomIncludeDependencies控制生成的 BOM 描述符中是否包含依赖项dependencies清单当前仓库将其在ThisBuild级别统一置为true即所有启用插件的模块生成的文件都会列出各自的实际依赖。而各模块依赖的版本定义集中在 project/Dependencies.scala 中统一维护例如scala213Version 2.13.17、reactiveStreamsVersion 1.0.4、jacksonCoreVersion 2.18.8等这些常量最终会被 sbt 解析为生成文件中的具体版本号。生成时机与 PR 工作流原文档对生成时机与提交流程给出了明确的工程约定File generation runs oncompile. It should be enough to add those generated files to the PR when changing the dependencies.这句话包含两层关键信息生成时机绑定compile任务只要执行 sbt 的compile插件就会重新生成对应的pom.xml。也就是说BOM 文件始终与当前依赖定义保持同步无需单独的额外命令或手工维护步骤。依赖变更时随 PR 提交当开发者修改了依赖例如在 project/Dependencies.scala 中升级某个库的版本本地编译后artifact-bom下相关模块的pom.xml会自动更新此时开发者只需把这些重新生成的文件一并加入同一个 PR就能保证代码变更与依赖清单变更同时被审查、同时入库。这是一条非常轻量的流程不要求开发者理解 BOM 的细节也不要求在 CI 中单独执行发布步骤只要遵循改依赖 → compile → 提交生成文件的习惯即可。从文档措辞should be enough只需这样做就够了可以看出这是项目刻意压低维护成本的设计取向。生成文件的结构深度解析为了让安全工具能够准确解析生成的pom.xml遵循标准的 Maven POM 4.0.0 格式。下面以几个实际生成的文件为例说明其结构。最小形态akka-actorartifact-bom/akka-actor/pom.xml 是结构最简单的例子project xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdcom.typesafe.akka/groupId artifactIdakka-actor/artifactId version100.0.0/version packagingpom/packaging dependencyManagement dependencies dependency groupIdcom.typesafe/groupId artifactIdconfig/artifactId version1.4.8/version /dependency dependency groupIdorg.scala-lang/groupId artifactIdscala-library/artifactId version2.13.17/version /dependency /dependencies /dependencyManagement dependencies dependency groupIdcom.typesafe/groupId artifactIdconfig/artifactId version1.4.8/version /dependency dependency groupIdorg.scala-lang/groupId artifactIdscala-library/artifactId version2.13.17/version /dependency /dependencies /project从中可以解读出几个关键设计packagingpom/packaging表明该文件是纯描述符不产生任何可执行或可打包的构建产物仅用于向工具暴露依赖信息。dependencyManagement以 Maven 的标准依赖版本管理语义锁定每个依赖的groupId、artifactId与精确version。顶层dependencies重复列出同样的依赖项。从仓库的生成结果看两部分内容保持一致这可以让只解析dependencies节点的扫描工具也能直接拿到完整清单。版本号完全对齐仓库依赖定义config 1.4.8、scala-library 2.13.17均可在 project/Dependencies.scala 中找到对应常量印证了生成文件与依赖定义实时同步的机制。version标签当前仓库生成文件的模块版本为100.0.0这是仓库自身的版本号可能为仓库快照期的占位版本实际内容以当前仓库文件为准。多依赖形态akka-streamartifact-bom/akka-stream/pom.xml 展示了带多个依赖的模块形态它在config、scala-library之外还锁定了流编程规范库dependency groupIdorg.reactivestreams/groupId artifactIdreactive-streams/artifactId version1.0.4/version /dependencyreactive-streams 1.0.4同样与 project/Dependencies.scala 中val reactiveStreamsVersion 1.0.4完全一致。复杂形态akka-cluster-shardingartifact-bom/akka-cluster-sharding/pom.xml 是依赖最丰富的例子之一其dependencyManagement中锁定了十余个依赖涵盖本地调用与原生接口绑定com.github.jnr:jffi、jnr-ffi、jnr-constants、jnr-a64asm、jnr-x86asm如 1.3.13、2.2.17 等版本ASN.1 编解码com.hierynomus:asn-one0.6.0配置库com.typesafe:config1.4.8高性能数据结构与内存映射库org.agrona:agrona1.22.0、org.lmdbjava:lmdbjava0.9.1字节码操作org.ow2.asm:asm系列asm、asm-analysis、asm-commons、asm-tree、asm-util均为 9.7.1响应式流规范与日志门面org.reactivestreams:reactive-streams1.0.4、org.slf4j:slf4j-api2.0.18Scala 标准库org.scala-lang:scala-library2.13.17这些依赖版本与 project/Dependencies.scala 中的agronaVersion 1.22.0、slf4jVersion 2.0.18等常量一一对应可见 BOM 生成是集中式依赖定义向机器可读描述符的自动映射。轻量形态akka-persistence-sharedartifact-bom/akka-persistence-shared/pom.xml 则只依赖scala-library一个库说明 BOM 的内容完全由模块自身的真实依赖决定不掺入任何多余条目。安全扫描对接Wiz 与软件供应链治理原文档明确了生成文件的下游消费者The generated file is then scanned by Wiz.即这些pom.xml生成后会被Wiz安全平台扫描。从文档上下文support our security tooling、scanned by Wiz以及文档中附带的 Wiz 项目状态页面可以看出这套机制的典型工作方式是每个 Akka 模块在compile时自动生成精确到版本的 Maven 依赖清单开发者修改依赖后把重新生成的 BOM 文件随 PR 提交使仓库中的清单始终反映最新依赖状态Wiz 等安全工具扫描这些 BOM 描述符将清单中的组件与已知漏洞数据库进行比对从而在依赖引入的第一时间暴露存在已知 CVE 风险的组件版本。这种做法的核心价值在于依赖可见性Akka 是一个横跨 actor、stream、cluster、persistence、remote 等数十个模块的大型多模块项目各模块的依赖规模和类型差异巨大从单个scala-library到 cluster-sharding 的十余个依赖。若依赖信息只散落在 sbt 的build.sbt、project/Dependencies.scala与各模块配置中安全工具将难以统一、稳定地解析而通过构建期自动生成的标准化 Maven POM工具获得了一份开箱即用的精确物料清单无需理解 sbt 的 DSL 语法即可完成组件分析。需要说明的是本文对 Wiz 扫描工作方式的具体细节扫描触发方式、漏洞库对接、报告展示等属于从文档与目录结构推断的合理理解仓库本身只确认了生成 → 提交 → 由 Wiz 扫描这一链路。模块覆盖范围一览从仓库实际目录看artifact-bom目前覆盖了以下模块对应 artifact-bom 下的子目录Actor 与测试akka-actor、akka-actor-typed、akka-actor-testkit-typed、akka-testkit、akka-stream-testkit流处理akka-stream、akka-stream-typed集群与分布式akka-cluster、akka-cluster-typed、akka-cluster-metrics、akka-cluster-sharding、akka-cluster-sharding-typed、akka-cluster-tools、akka-remote、akka-multi-node-testkit、akka-coordination、akka-discovery持久化akka-persistence、akka-persistence-typed、akka-persistence-query、akka-persistence-shared、akka-persistence-tck、akka-persistence-testkit、akka-distributed-data基础设施与集成akka-protobuf-v3、akka-serialization-jackson、akka-slf4j、akka-pki这些模块的生成结果与 build.sbt 中enablePlugins(ArtifactBomPlugin)的分布相互印证。若未来新增模块需要纳入安全扫描范围只需在模块定义上追加一行.enablePlugins(ArtifactBomPlugin)并在compile后提交新生成的pom.xml即可。小结一套低成本的依赖安全基线akka-core 的artifact-bom机制给出了一条清晰的工程范式用构建期自动生成 PR 随变更提交的方式为安全扫描工具持续提供精确、标准、始终新鲜的依赖清单。它不要求开发者手工维护 XML不增加 CI 的额外负担只通过 sbt 插件在compile阶段的自动输出就把依赖定义这一单一事实源同步为安全工具可消费的 Maven 描述符。对于任何希望在大型多模块项目中落地软件供应链安全扫描的团队这套插件生成 → 文件入库 → 工具扫描的组合都是值得参考的轻量级实践。若想深入验证或复现可以直接阅读仓库中的 artifact-bom/README.md、project/plugins.sbt、project/AkkaBuild.scala、build.sbt 以及 artifact-bom 目录下各模块的pom.xml文件。【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址: https://gitcode.com/gh_mirrors/ak/akka-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
