【问题标题】:Maven multimodule project composition regarding dependencies sharing关于依赖共享的Maven多模块项目组合
【发布时间】:2011-09-14 22:19:24
【问题描述】:

有几个类似的问题,但没有这样的。您如何处理这种情况(典型场景):

一个包含 8-11 个子项目的项目,有一个父项目/项目和一个主要使用/声明其他项目作为模块的主项目。

问题是所有项目都“严格”共享公共依赖项,例如testng, logging, apache commons and stuff。但总是像 其中 3 个使用 50-60% 的相同特定依赖项(apache-chemistry、jackrabbit、abdera 等),另外 2-3 个也使用 50-60% 相同但不同的依赖项.主要的使用了很多相同的部门。

我不能将那些“非严格”共享的部门放入父项目中以供其他人继承。所以只有共同的部门被继承。并且有大量重复的依赖项。而且我只能通过<dependencyManagement>管理他们的版本。

另一种选择是让父 pom 包含大部分依赖项,但子项目甚至会继承它们不需要的那些。

我可以有多个父项目,但感觉不对。从父项目继承也可能是一场噩梦,因为如果您没有正确记录/注释父 pom 定义,您不知道项目需要哪些依赖项。

另一种方法是创建仅用作依赖容器的 pom 工件 - 它们声明特定的依赖组,因此模块只需声明这些依赖即可获得传递依赖。但是,嘿,你想部署并提交某种形式的

OneDepArtifact 声明 jackrabit, abdera, chemistry

另一个DepArtifact 声明htmlcleaner, google-api, tika

ThirdDepArtifact 声明 spring, httpclient, selenium

这是一个巨大的混乱,我不确定我是否正确使用<dependencyManagement>,它似乎只对管理依赖版本有用。

我正在考虑让我的应用开发适应“maven 多模块设计”。但是如果你想在一个模块中创建只使用各种库的spring服务/bean,你不要在不同的模块中实现它们,只是因为它们使用了其他模块也使用的库:-)

【问题讨论】:

  • 我也有同样的问题。我喜欢管理多模块项目,因为它带来了其他好处,但是如果项目变得很大,这种跨模块依赖共享是一场噩梦。
  • 也许必须让实际的应用程序开发适应多模块项目设计,并尝试创建这样的组件,这样就不会有任何依赖项重用......但这似乎不是对

标签: java inheritance dependencies maven-3 multi-module


【解决方案1】:

Maven 3.1 应该通过引入“mixins”来解决这个问题。与此同时,我似乎可以通过正确使用配置文件来获得大部分所需的功能,正如我在这篇博文中所描述的那样:

http://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

如果你觉得它有用,请告诉我。

【讨论】:

    【解决方案2】:

    我知道你说这可能是一场噩梦,但我强烈认为你的父母 pom 之间的继承是要走的路。

    我在this answer 中描述了一个很好的多模块项目结构。它还描述了使用聚合器和父链继承。

    一些可以帮助您保持井井有条的事情......

    • 使用良好的命名约定;不要只调用父项目parent1parent2。使用描述他们配置的依赖类型和其他内容的名称,以便人们直观地知道何时使用哪个。
    • 使用 maven 的发布/部署功能,以便在您的存储库中正确地对它们进行版本控制,并始终引用固定版本的工件。不使用 SNAPSHOT 是获得确定性、可重复构建的第一步。在动态变化时调试问题非常困难。
    • 不要依赖 pom.xml 文件来了解您的项目需要哪些依赖项。这将导致您避免继承和其他事情,如自定义配置文件。您应该使用maven-dependency-plugin 来执行这些分析任务。有像 mvn dependency:tree 这样的命令,可以显示项目的所有依赖项,mvn dependency:analyze 可以显示未使用的依赖项。

    希望有了这个建议,父 POM 文件继承不会显得那么复杂和噩梦。祝你好运!

    【讨论】:

    • 我只有一个父目录/pom(继承自 SuperPom 并聚合所有 10 个模块)和同一级别的模块 dirs/pom。模块从父级继承,它们是它的模块。但是,我已经按照您的建议做了所有事情。我相信我只需要接受它本来的样子。我不想用 3 个子父级链接继承...我真的希望所有模块都在多模块项目中声明所有这些重复的依赖项
    • @lisak - 为什么宁愿重新声明所有重复的依赖项而不是使用继承?此外,您应该尝试使您的父 pom 与聚合器 pom 不同。以我的经验,这总是让事情变得更容易。我在链接到的答案中描述了这种布局。
    • 如果共享依赖是使模块成为兄弟的唯一方面,那么链式继承是多余的。如果还有一些插件或构建阶段的东西要继承,为什么不呢。但除此之外,我发现它更容易使用。此外,很难跟踪在依赖项中列出的未使用声明的运行时/测试依赖项:分析......只是我不在乎我是否使用它,也许这是主要问题,这个功能的存在不会带来任何在这种情况下让我松了一口气:-)
    【解决方案3】:

    如果它主要是关于版本(数字)控制 - 为什么不在父项目中仅指定依赖版本作为属性并在子项目中使用它,例如

    家长

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
        <groupId>foo.bar</groupId>
        <artifactId>maven-parent</artifactId>
        <version>0.0.1</version>
        <packaging>pom</packaging>
    
        <properties>
            <log4j.version>1.2.16</log4j.version>
        </properties>
    
    </project>
    

    儿童

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
        <parent>
            <artifactId>maven-parent</artifactId>
            <groupId>foo.bar</groupId>
            <version>0.0.1</version>
        </parent>
    
        <groupId>foo.bar</groupId>
        <artifactId>maven-child</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    
        <dependencies>
            <dependency>
                <groupId>log4j</groupId>
                <artifactId>log4j</artifactId>
                <version>${log4j.version}</version>
            </dependency>
        </dependencies>
    
    </project>
    

    这是一个简单的解决方案,可让您指定具有一致版本号的特定项目依赖项。

    【讨论】:

    • 这根本不是关于版本控制,这只是 有好处的事情......我没有版本地狱的问题,不像其他人......我在问题是,这是我唯一可以控制的事情......我将属性与dependencyManagement结合起来,基于什么是继承的,什么不是
    • 问题是所有这些pom中依赖的数量和重复,即使你有版本在控制之下,在一个大项目中也很难维护
    猜你喜欢
    • 2011-09-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-06-15
    • 1970-01-01
    相关资源
    最近更新 更多