JFrog Artifactory的Maven项目推荐布局设置

69次阅读

问题描述

在使用JFrog Artifactory服务时，希望将所有的构件存储在Artifactory服务器中，用于依赖管理和发布管理。用户已经创建了一个名为’myartifactory’的本地仓库，并计划在项目的pom.xml文件中使用以下代码进行分发管理。

<distributionManagement>
    <repository>
        <id>central</id>
        <name>jd-releases</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>jd-snapshots</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </snapshotRepository>
</distributionManagement>

用户想知道上述方法是否是推荐的方式？”Remote Repositories”和”Virtual Repositories”有什么作用？是否必须使用它们？能否给出一个实际的例子？
此外，Artifactory默认推荐了一些本地仓库的最佳实践，如下所示：

libs-release-local - 用于发布的代码
libs-snapshot-local - 用于快照的代码
ext-release-local - 手动部署的第三方库（发布版）
ext-snapshot-local - 手动部署的第三方库（快照版）
plugins-release-local - 自己和第三方插件（发布版）
plugins-snapshot-local - 自己和第三方插件（快照版）

用户对正确的方法感到困惑，欢迎提出建议。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

仓库类型

在Artifactory中，有三种类型的仓库：
1. 本地(Local)：本地仓库是物理的、本地管理的仓库，可以将构件部署到其中。
2. 远程(Remote)：远程仓库作为远程URL管理的仓库的缓存代理。
3. 虚拟(Virtual)：虚拟仓库（或”仓库组”）是相同包类型的多个仓库的聚合，具有共同的URL。

本地和远程仓库是真正的物理仓库（它们存在于您的服务器上或其他地方的远程服务器上），而虚拟仓库实际上是它们的聚合，用于创建受控的域，以便搜索和解析构件。

是否需要使用这些类型的仓库取决于您的使用情况。远程仓库的一个实际用例是Maven Central或jCenter，开发人员在这些服务中托管他们的Maven构件。JFrog Artifactory可以作为这些服务的缓存，以便不必每次解析Maven依赖时都要通过互联网。虚拟仓库的一个实际用例是我有一个远程仓库（如我已经提到的那些）和一些本地仓库（如您在问题中提到的那些）。我希望确保我的开发人员只需要配置一个Maven仓库URL，而我的虚拟仓库允许我这样做。通过虚拟仓库，我可以将各种其他仓库组合在一起，并给开发人员一个URL，以便我可以管理允许的依赖关系，而不是每次都从互联网解析它们。

基于我们的经验教训，我们在Artifactory中包含了一些默认仓库，这些仓库遵循大多数使用Maven的开发人员的流程。话虽如此，您完全可以采用自己的工作流程，而不使用默认仓库。