关于依赖关系共享的Maven多模块项目组成 [英] Maven multimodule project composition regarding dependencies sharing

问题描述

有一些类似的问题，但没有这样的。如何处理这种情况（典型情况）：

一个8-11个子项目的项目，有一个父工件/项目和一个主要项目，主要使用/声明其他人作为模块。

问题是所有项目严格仅共享常见的依赖关系，如 testng，logging，apache commons和东西。但总是喜欢 3个，它们使用相同特定部门（apache-chemistry，jackrabbit，abdera等）的50-60％，另外2-3个也使用相同但不同依赖关系的50-60％ 。而且主要使用了很多相同的deps。

我不能把这些非严格的共享deps放在父项目中，供其他人继承。所以只有普通的deps是继承的。而且有大量的重复依赖。我只能通过< dependencyManagement> 来管理他们的版本。

另一个选项是让父pom包含大部分依赖关系，但子项目继承甚至不需要它们。

我可以拥有超过1个父项目，但感觉不对。从父项目继承也可能是噩梦，因为您不知道项目需要什么依赖关系，如果您没有正确地记录/评论父pom定义。

另一种方法是创建仅用作依赖容器的pom工件，它们声明特定的依赖关系组，以便模块只是声明那些获取传递依赖关系。但是，嘿，你想部署和提交某种

OneDepArtifact声明 jackrabit，abdera，chemistry

AnotherDepArtifact声明 htmlcleaner，google-api，tika

ThirdDepArtifact声明 spring，httpclient，selenium

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

我正在考虑将我的应用程序开发调整为maven multimodule design。但是，如果要创建spring服务/ bean，那么只需使用各种库，就可以在一个模块中使用不同的模块，因为它们使用的是其他模块使用的库： - ）

解决方案

Maven 3.1应该通过引入mixins来解决这个问题。在此期间，我可以通过正确使用个人资料来获取大部分所需的功能，正如我在这篇博文中所描述的那样：

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

请让我知道你是否觉得有用。 p>

There are a few similar questions, but nothing like this. How do you deal with this situation (typical scenario) :

A project of 8-11 child projects, having a parent artifact/project and one main project that mostly uses/declares those others as modules.

The problem is that all projects "strictly" share only the common dependencies, like testng, logging, apache commons and stuff. But always like 3 of them use 50-60% of the same specific deps (apache-chemistry, jackrabbit, abdera, etc.), another 2-3 of them also use 50-60% of the same but different dependencies. And the main one uses a lot of the same deps.

I cannot put those "non-strictly" shared deps into parent project for others to inherit them. So only the common deps are inherited. And there is tons of duplicate dependencies. And I can only manage their versions via <dependencyManagement>.

Another option is having parent pom contain most of the dependencies, but child projects inherit even those they don't need.

I could have more than 1 parent project, but it doesn't feel right. Also inheritance from parent project could be nightmare, because you don't know what dependencies the project needs, if you don't document/comment the parent pom definition properly.

Another way is to create pom artifacts that serves only as dependency containers - they declare specific groups of dependencies, so that modules just declare those to gain transitive dependencies. But hey, would you like to deploy and commit some sort of

OneDepArtifact declaring jackrabit, abdera, chemistry

AnotherDepArtifact declaring htmlcleaner, google-api, tika

ThirdDepArtifact declaring spring, httpclient, selenium

It's a huge mess, I'm not sure if I use <dependencyManagement> correctly, it seems to be only useful for managing dependency versions.

I was thinking of adapting my app development to "maven multimodule design". But If you want to create spring services/beans, that just use various libraries, in one module, you don't implement them in different module, just because they use library that other module also uses :-)

解决方案

Maven 3.1 should solve this problem by introducing "mixins". In the meantime, it seems that I can get most of the needed features by the proper use of profiles, as I described in this blog post:

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

Please let me know whether you find it useful.

这篇关于关于依赖关系共享的Maven多模块项目组成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！