Maven通过存储库定义从项目依赖项中排除插件

Question

我正在评估Maven以构建公司软件。 我的特殊情况是，所有允许在生产中使用的工件都受到限制。

批准的库通过特殊存储库维护（在Artifactory实例中）。

虽然最终产品受到限制，但我们可能会使用更多依赖项进行构建（Maven插件及其依赖项的限制较小）。

因此，我在pom和pluginRepository配置了repository部分。

现在的问题是，所有已解决的工件（用于插件和项目）都仅缓存在一个本地存储库/文件夹中。 如果由于maven-plugin偶然将编译依赖项添加到仅在缓存中的任何项目，它将在没有任何警告的情况下使用。

我删除了本地存储库，并重新编译了测试项目，并且构建失败，依赖关系无法解决。

我已经在网上搜索了，但没有找到针对该问题的具体答案。 在Maven上有一个待处理的请求，用于为每个存储库分离本地缓存，但是似乎仅在Maven 4状态下进行过审查： https : //cwiki.apache.org/confluence/display/MAVEN/Local+Repository+Separation

https://issues.apache.org/jira/browse/MNG-3655 https://issues.apache.org/jira/browse/MNG-4302

maven-enforcer-plugin在这里具有bannedDependencies的概念，但这需要大量的配置才能开始，理想情况下，我想跟上当前批准的发行版，而无需进行手动交互。

有什么想法吗？ 我错过配置了吗？

更新1：

好吧，即使试图列出强制实施程序插件中所有允许的依赖关系，对我也不起作用：

   <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.2</version>
    </dependency>
    ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-enforcer-plugin</artifactId>
            <version>1.4.1</version>
            <executions>
                <execution>
                    <id>enforce-versions</id>
                    <goals>
                      <goal>enforce</goal>
                    </goals>
                    <configuration>
                        <rules>
                            <bannedDependencies>
                                <excludes>
                                    <exclude>*:*</exclude>
                                </excludes>
                                <includes>
                                    <include>commons-io:commons-io:1.4</include>
                                    ...
                                </includes>
                            </bannedDependencies>
                        </rules>
                        <fail>true</fail>
                    </configuration>
                </execution>
            </executions>
        </plugin>

此处的构建应该失败，但是[INFO] BUILD SUCCESS 。

更新2：

更令人惊讶的是，在Maven文档中，该问题已通过版本3中的更改得以解决： https : //cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes ＃Maven3.xCompatibilityNotes-ResolutionfromLocalRepository

本地存储库中的解析Maven 3.x使用的本地存储库已得到增强，可以跟踪从中解析工件的远程存储库。 有关工件来源的信息用于确保构建仅在配置了适当存储库的情况下才能访问本地缓存的工件。 因此，在使用Maven 3进行构建时，在其POM中缺少必需的远程存储库的项目可能会失败。这可以通过消除通过本地存储库进行意外工件共享的影响来提高构建的可重复性。

Answer 1

好吧，我最终确定了引起我头痛的原因。 首先，我要有一个独立的项目。 无需特殊的用户settings.xml即可运行（如果需要切换，其镜像会阻止其他项目运行）。

正如我说的那样，我不希望该构建使用他所不允许的构件，因此我必须重新配置Maven Central，使其无法访问。 这就是我的方法：

<repository>
  <id>central</id>
  <url>http://${company-repo-manager}/${project-repository}</url>
</repository>
...
<pluginRepository>
  <id>central</id>
  <url>http://${company-repo-manager}/${plugin-repository}</url>
</pluginRepository>

我看起来是个好主意，但遇到上述问题，无法将来自插件和项目依赖项的本地缓存的工件混合在一起。

现在我知道Maven 3应该引入一种本地回购管理，我仔细查看了我的本地存储库，发现了一个名为_remote.repositories的文件， _remote.repositories包含以下内容：

commons-io-2.2.jar>central=
commons-io-2.2.pom>central=

在这里，您可以看到maven记住了工件的来源存储库，但它记住了存储库ID，而不是URL！ 当我确实配置了我的插件存储库和项目存储库时，都使用id central Maven混合了两个存储库的缓存工件。

解决方案最后是尝试禁用中央存储库，并使用单独的名称配置项目和插件存储库：

<repository>
  <id>${project-repository}</id>
  <url>http://${company-repo-manager}/${project-repository}</url>
</repository>
<repository>
  <id>central</id>
  <name>Maven Central</name>
  <url>http://repo1.maven.org/maven2</url>
  <releases>
     <enabled>false</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>
...
<pluginRepository>
  <id>maven-plugins-repo</id>
  <url>http://${company-repo-manager}/${plugin-repository}</url>
</pluginRepository>
<pluginRepository>
  <id>central</id>
  <name>Maven Central</name>
  <url>http://repo1.maven.org/maven2</url>
  <releases>
     <enabled>false</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</pluginRepository>

不幸的是， 您无法从解决方案中删除Central ，因此，如果不同的项目使用名为Central的存储库，则它们将与本地构建交互。

Maven Enforcer是一个插件，我仍然会寻找它，但这至少是我试图解决的基本配置问题。

如果我从干净的缓存开始（例如，在CI构建中），我将得到我期望的构建失败。

希望能对尝试达到这种隔离水平的人有所帮助。 由于您无法删除中央存储库，并且工件描述符在所有存储库中都应相同，因此它仍然不是完美的，但是我们至少提供了最少的支持。