Maven - “所有”或“父母”聚合项目?

发布于 2024-08-31 22:48:31 字数 977 浏览 5 评论 0原文

出于教育目的,我设置了一个像这样的项目布局(扁平化是为了更好地适应 Eclipse):

-product
 |
 |-parent
 |-core
 |-opt
 |-all

Parent 包含一个包含 core、opt 和 all 的聚合项目。核心实现应用程序的强制部分。 Opt是可选部分。 All 应该将 core 与 opt 结合起来,并将这两个模块列为依赖项。

我现在正在尝试制作以下工件:

  1. product-core.jarproduct
  2. -core-src.jarproduct
  3. -core-with-dependency.jarproduct
  4. -opt.jarproduct
  5. -opt-src.jarproduct
  6. -opt-with-dependency .jarproduct
  7. -all.jarproduct
  8. -all-src.jarproduct
  9. -all-with-dependency.jar

其中大多数的生成相当简单。不过,我在聚合工件方面确实遇到了一些问题。我已经成功地在“all”模块中使用自定义程序集描述符制作了product-all-src.jar,该描述符下载所有非传递依赖项的源代码,并且效果很好。这种技术还允许我制作 Product-all-with-dependencies.jar。

然而,我最近发现您可以使用源插件中的 source:aggregate 目标来聚合整个聚合项目的源。对于 javadoc 插件也是如此,它也通过父项目的使用进行聚合。

因此,我在“所有”模块方法和放弃“所有”模块并仅使用“父”模块进行所有聚合之间左右为难。在“父级”中生成一些聚合工件,而在“全部”中生成其他工件,这感觉很不干净。有没有办法在父项目中制作“product-all”jar,或者在“all”项目中聚合javadoc?或者我应该两者都保留?

谢谢

For educational purposes I have set up a project layout like so (flat in order to suite eclipse better):

-product
 |
 |-parent
 |-core
 |-opt
 |-all

Parent contains an aggregate project with core, opt and all. Core implements the mandatory part of the application. Opt is an optional part. All is supposed to combine core with opt, and has these two modules listed as dependencies.

I am now trying to make the following artifacts:

  1. product-core.jar
  2. product-core-src.jar
  3. product-core-with-dependencies.jar
  4. product-opt.jar
  5. product-opt-src.jar
  6. product-opt-with-dependencies.jar
  7. product-all.jar
  8. product-all-src.jar
  9. product-all-with-dependencies.jar

Most of them are fairly straightforward to produce. I do have some problem with the aggregating artifacts though. I have managed to make the product-all-src.jar with a custom assembly descriptor in the 'all' module which downloads the sources for all non-transitive deps, and this works fine. This technique also allows me to make the product-all-with-dependencies.jar.

I however recently found out that you can use the source:aggregate goal in the source plugin to aggregate sources of the entire aggregate project. This is also true for the javadoc plugin, which also aggregates through the usage of the parent project.

So I am torn between my 'all' module approach and ditching the 'all' module and just use the 'parent' module for all aggregation. It feels unclean to have some aggregate artifacts produced in 'parent', and others produced in 'all'. Is there a way of making an 'product-all' jar in the parent project, or to aggregate javadoc in the 'all' project? Or should I just keep both?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

风吹雨成花 2024-09-07 22:48:31

压扁的树木不再经常使用。这是几年前做的,目的是解决 Eclipse 处理项目的方式以及 Maven 和 Eclipse 缺乏良好集成的问题。如果您使用 m2eclipse 将 Maven 项目导入 Eclipse,那么对于 Maven 典型的嵌套树,您不会遇到任何问题。

至于如何构建 Maven 构建的一个很好的例子是什么? Maven 项目源本身。它拥有您想要的所有部分,包括最终的 程序集 打包捆绑包。

典型的嵌套结构具有自上而下的层次结构,其中父级对其下面的模块进行聚合,而子级从父级继承值。尽管这些有时可以是分开的,但这不是常态。

Flattened trees are not often used anymore. This was done several years ago to deal with how Eclipse handled projects and the lack of good Maven and Eclipse integration. If you use m2eclipse to import Maven projects into Eclipse, you won't have any problems with a maven-typical nested tree.

As far as what is a good example of how to structure a Maven build? The Maven project source itself. It has all the pieces you desire, including the final assembly that packages up the bundles.

The typical nested structure has a top down hierarchy where the parent is doing the aggregation of the modules below it, and the children are inheriting values from the parent. Although these can and sometimes are separate, this is not the norm.

青春有你 2024-09-07 22:48:31

我建议将程序集描述符保留在“all”中,将其移动到parent/并相应地更改parent/pom.xml,然后通过执行类似mvn -fparent/pom.xml程序集的操作来创建该程序集:程序集。换句话说,是的,删除“所有”的冗余项目,因为它只是重复“父”已经在做的事情。

顺便说一句,如果该项目是一个聚合项目而不仅仅是一个父 pom.xml,那么“parent”似乎是一个糟糕的命名选择。

[编辑]

虽然是一个更大的项目,但也许按照您的设想布局的项目是 apache Camel 项目。在这里查看: http://camel.apache.org/source.html 。有一个父/模块处理所有其他事情,还有一个单独的模块用于在 apache-camel/ 中生成实际的构建发行版(在 apache-camel/src//main/descriptors 中具有程序集描述符)。也许这会更有帮助。

I'd suggest just keeping the assembly descriptor from "all", move it to parent/ and change parent/pom.xml accordingly, and then create that assembly by doing something like mvn -f parent/pom.xml assembly:assembly. In other words, yeah, remove the redundant project for "all" since it is just duplicating what "parent" is already doing.

On a side note, "parent" seems like a poor naming choice for that project if it's an aggregate project and not just a parent pom.xml.

[Edit]

Although a much larger project, perhaps a project that is laid out how you are envisioning is the apache camel project. Check it out here: http://camel.apache.org/source.html . There is a parent/ module that handles all of the for everything else, and a separate module for producing the actual build distributions in apache-camel/ (with assembly descriptors in apache-camel/src//main/descriptors). Perhaps that will be more of a help.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文