ChatGPT解决这个技术问题 Extra ChatGPT

排除单个依赖项的所有传递依赖项

在 Maven2 中,要排除单个传递依赖项,我必须执行以下操作:

<dependency>
  <groupId>sample.group</groupId>
  <artifactId>sample-artifactB</artifactId>
  <version>1</version>
   <exclusions>
     <exclusion>
       <groupId>sample.group</groupId>
       <artifactId>sample-artifactAB</artifactId>
     </exclusion>
   </exclusions>
</dependency>

这种方法的问题在于,我必须为 sample-artifactB 贡献的每个传递依赖项执行此操作。

有没有办法使用某种通配符来一次排除所有传递依赖项而不是一个接一个?

有时需要使用最新版本的库,比如 Spring 2.5.6,但其他一些依赖项包括旧版本,例如 struts2-spring-plugin (2.1.6) 包括 Spring 2.5.3。在这种情况下,需要排除或覆盖版本。
使用常春藤。只是在开玩笑。

m
mhcomputing

对我有用的东西(可能是 Maven 的一个新特性)只是在排除元素中使用通配符。

我有一个多模块项目,其中包含在两个 WAR 打包模块中引用的“应用程序”模块。其中一个 WAR 打包的模块实际上只需要域类(我还没有将它们从应用程序模块中分离出来)。我发现这个工作:

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>app</artifactId>
    <version>${project.version}</version>
    <exclusions>
        <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

groupId 和 artifactId 上的通配符排除了所有通常会传播到使用此依赖项的模块的依赖项。


组和工件的 * 通配符似乎在 maven 3 中工作
我不知道你是如何找到这个工作的,因为 Maven 3 明确警告使用星号:[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for with value "*" does not匹配有效的 id 模式。 [警告] 强烈建议修复这些问题,因为它们会威胁您构建的稳定性。 [警告] 出于这个原因,未来的 Maven 版本可能不再支持构建这种格式错误的项目您介意提供一些证据证明它受支持并且可以使用吗?否则我会认为你的评论极具误导性。
与 Maven 3.0.4 完美配合。非常感谢!
maven 3.0.4 -> 它对我来说效果不佳。当我使用 asterix 或当我明确排除所有直接依赖项时,产生的 jar 非常不同。这可能与我使用 maven-assembly-plugin 创建一个胖 jar 的事实有关。在这种情况下,建议的 sulotion 不起作用!
这种方法是有效的。他们修复了其他人在 maven 3.2.1 中报告的警告:issues.apache.org/jira/browse/MNG-3832
C
Community

对于 maven2,没有办法按照您的描述进行操作。对于 Maven 3,有。如果您使用的是 maven 3,请参阅 another answer for this question

对于 maven 2,我建议为具有 的依赖项创建自己的自定义 pom。对于需要使用该依赖项的项目,请将依赖项设置为您的自定义 pom 而不是典型的工件。虽然这不一定允许您使用单个 排除所有传递依赖项,但它确实允许您只需要编写一次依赖项,并且您的所有项目都不需要维护不必要的长排除列表。


我建议不要制作自己的 pom 来解决排除问题。这使您的构建变得不那么可移植并降低了理解力。
如果您没有看过去接受的答案:jira.codehaus.org/browse/MNG-3832
@JakubBochenski 我给出的答案是针对 maven 2 的,这就是这个问题的标签(在我写这篇评论的时候)。您的链接仅与 maven 3 相关。无论如何,我已经编辑了我的答案以链接到更受好评的答案。
J
Joshua Davis

我发现有用的一件事:

如果您将带有排除项的依赖项放在项目的父 POM 的 dependencyManagement 部分中,或者放在可导入的依赖项管理 POM 中,则无需重复排除项(或版本)。

例如,如果您的父 POM 具有:

<dependencyManagement>
    <dependencies>
    ...         
        <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
            <version>1.2.1</version>
            <exclusions>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
     ....
  </dependencies>
</dependencyManagement>

然后您项目中的模块可以简单地将依赖项声明为:

        <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
        </dependency>

父 POM 中的 将指定版本和排除项。我几乎在我们所有的项目中都使用了这种技术,它消除了很多重复。


C
Community

Three years ago 我建议使用版本 99 不存在,但现在我想出了一个更好的方法,特别是因为版本 99 已离线:

在项目的父 POM 中,如果不需要的依赖项蔓延到构建中,请使用 maven-enforcer-plugin 使构建失败。这可以使用插件的 banned dependencies 规则来完成:

<plugin>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>1.0.1</version>
    <executions>
        <execution>
            <id>only-junit-dep-is-used</id>
            <goals>
                <goal>enforce</goal>
            </goals>
            <configuration>
                <rules>
                    <bannedDependencies>
                        <excludes>
                            <exclude>junit:junit</exclude>
                        </excludes>
                    </bannedDependencies>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

然后,当它提醒您有关不需要的依赖项时,将其排除在父 POM 的 <dependencyManagement> 部分中:

<dependency>
    <groupId>org.springframework.batch</groupId>
    <artifactId>spring-batch-test</artifactId>
    <version>2.1.8.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </exclusion>
    </exclusions>
</dependency>

这样,不需要的依赖项就不会意外出现(不像 <exclusion> 那样容易忘记),即使在编译时也不可用(不像 provided 范围),没有虚假的依赖项(不像版本 99),它可以在没有自定义存储库的情况下工作(与版本 99 不同)。这种方法甚至可以根据工件的版本、分类器、范围或整个 groupId - see the documentation 了解详细信息。


请注意,至少在 Maven 3.1 下,从命令行执行目标时会忽略 <configuration>,必须直接在 <plugin> 下向上移动。
我刚刚发现了一个看起来很讨厌的 Maven 错误 - 版本 3.5.2。我有一个带有子模块的项目,我确实在父级的 <dependencyManagement> 部分排除了依赖项。在该特定项目中运行 mvn dependency:tree 将完全没有排除的依赖项。但是所有导入该依赖项的项目都不会遵守来自另一个项目父 pom 的 <exclusions> - 被排除的项目将潜入!!!我不得不将 <exclusions> 直接移动到每个模块 pom。
M
Michael Zilbermann

我使用以下解决方法:我没有尝试在所有适当的依赖项中排除工件,而是在顶层将依赖项绘制为“提供”。例如,为了避免发送 xml-apis "whatever version" :

    <dependency>
        <groupId>xml-apis</groupId>
        <artifactId>xml-apis</artifactId>
        <version>[1.0,]</version>
        <scope>provided</scope>
    </dependency>

P
Paulo Merson

目前,没有办法一次排除多个传递依赖,但在 Maven JIRA 站点上有一个功能请求:

https://issues.apache.org/jira/browse/MNG-2315


R
Rich Seller

有一个解决方法,如果将依赖项的范围设置为运行时,将排除传递依赖项。尽管请注意,这意味着如果要打包运行时依赖项,则需要添加额外的处理。

要在任何打包中包含运行时依赖项,您可以使用 maven-dependency-plugin 的 copy goal for a specific artifact


这帮助我解决了 Android Dalvik 编译器无法处理某些两级传递包含的问题——但我不得不使用 <scope>provided</scope> 而不是 <scope>runtime</scope>
S
Superole

如果您需要从要包含在程序集中的依赖项工件中排除所有传递依赖项,则可以在程序集插件的描述符中指定:

<assembly>
    <id>myApp</id>
    <formats>
        <format>zip</format>
    </formats>
    <dependencySets>
        <dependencySet>
            <useTransitiveDependencies>false</useTransitiveDependencies>
            <includes><include>*:struts2-spring-plugin:jar:2.1.6</include></includes>
        </dependencySet>
    </dependencySets>
</assembly>

g
gnat

如果您在 Eclipse 下开发,您可以在 POM 编辑器(启用高级选项卡)依赖关系图中查找要从项目中排除的依赖关系,然后:

右键单击它->“排除 Maven Artifact ...”,Eclipse 将为您进行排除,而无需找出 lib 链接的依赖项。


请注意,这仅在您使用 m2eclipse 插件时才有效
C
Community

你排除所有传递依赖的原因是什么?

如果您需要从每个依赖项中排除特定的工件(例如 commons-logging),则 Version 99 Does Not Exist 方法可能会有所帮助。

2012 年更新:不要使用这种方法。使用 maven-enforcer-plugin and exclusions。版本 99 产生虚假的依赖关系,版本 99 存储库处于脱机状态(有 similar mirrors,但您也不能依赖它们永远在线;最好只使用 Maven Central)。


n
nkr1pt

在一个类似的问题中,我使用提供的范围声明了所需的依赖项。使用这种方法,可以获取传递依赖项,但不包含在包阶段,这是您想要的。在维护方面我也喜欢这个解决方案,因为不需要维护 pom 或 whaley 解决方案中的自定义 pom;你只需要在容器中提供具体的依赖就可以了


S
Samraj

在您的类路径中使用最新的 maven .. 它将删除重复的工件并保留最新的 maven 工件..