Maven项目设计或反模式设计的好方法 [英] Good approach of a maven project design or antipattern design

问题描述

上下文:

我有一个如下所示的多模块Maven项目:

I have a multimodules maven project that looks like:

根---- ModuleA

Root ---- ModuleA

      ModuleB
      ModuleC
      ModuleD
      .......

它们在根目录下大约有25个模块:

They are around 25 modules under the Root:

• 其中一些代表应用程序的核心(5个模块)
• 其余每个模块代表与客户类型相关的业务流程实现.这些模块彼此完全独立.

打包或发布"Root"项目时，生成的工件是单个ZIP文件，该文件汇总了与"Root"模块相关的所有JAR.

When packaging or releasing the 'Root' project, the artifact generated is a single ZIP file aggregating all the JARs related to 'Root' modules.

单个ZIP文件是根据程序集描述符生成的，它表示交付工件.

The single ZIP file is generated according to an assembly descriptor, it represents the delivery artifact.

在目标环境上部署时，单个ZIP文件被解压缩到一个目录下，该目录由引擎"(提供最终服务的Java Web应用程序)使用(加载类).

At deployment time on the target environment, the single ZIP is unziped under a directory where it is consumed (class loaded) by an 'engine', a java web application that provides the final services.

约束

• 从一侧来看，业务约束"，
• 并且愿意减少不同版本之间的回归 另一边

• The 'business constraints' from one side,
• And the willing to reduce regressions between different versions on the other side

以上限制导致我们采用以下发布方案:

The above constraints lead us to adopt the following release scenarios:

• 我们要么释放Root并 ALL 子模块.代表着 生成的ZIP将以相同的方式聚合所有子模块JAR 版本. ZIP将包含类似于以下内容的内容: [ModuleA-1.1.jar，ModuleB-1.1.jar，ModuleC-1.1.jar，ModuleD-1.1.jar， .......，ModuleX-1.1.jar].

• Either we release the Root and ALL its submodules. It means that the resulting ZIP will aggegate all the submodules JAR with the same version. The ZIP will contain something similar to: [ModuleA-1.1.jar, ModuleB-1.1.jar, ModuleC-1.1.jar, ModuleD-1.1.jar, ......., ModuleX-1.1.jar].

或者我们发布其根目录和一个FEW 子模块，这些子模块是我们要重新更新的子模块. 生成的ZIP将合并所有子模块JAR:已发布的子模块将与最近发布的版本聚合，未发布的子模块将与另一个合适的"版本聚合. 例如，如果我们发布了这样的增量版本，则ZIP中将包含类似于[ModuleA-1.2.jar，ModuleB-1.1.jar，ModuleC-1.2.jar，ModuleD-1.1.1.jar， .......，ModuleX-1.1.2.jar].

Or we release the Root and A FEW of its submodules, the ones that we want to re update. The resulting ZIP will aggegate all the submodules JAR : The released submodules will be aggregated with the last released versions, the unreleased submodules will be aggregated with another 'appropriate' version. For example, if we made a such incremental release, the ZIP will contain something similar to [ModuleA-1.2.jar, ModuleB-1.1.jar, ModuleC-1.2.jar, ModuleD-1.1.1.jar, ......., ModuleX-1.1.2.jar].

这两种情况是通过以下方式实现的:

These 2 scenarios were made possible by:

• 首先将模块声明为 MAVEN MODULES'module' 场景
• 或将模块声明为已依赖" 第二种情况是INCREMENTAL情况.

• Either declaring the modules as MAVEN MODULES 'module' for the first scenario
• Or declaring the modules as MAVEN DEPENDENCIES 'dependency' for the second scenario, the INCREMENTAL scenario.

问题

在第二种方案(INCREMENTAL)中，两种方案均能很好地工作，但但，maven-release-plugin:prepare会将所有模块[ModuleA，ModuleB]上载到SCM(svn). ，ModuleD，.... ModuleX]，它将上传已发布和未发布的模块，而未发布的模块"在pom中声明为依赖项"，而不是模块".

Both scenarios are working perfectly BUT when we are in the 2nd scenario (INCREMENTAL), the maven-release-plugin:prepare is uploading to the SCM (svn) all the modules [ModuleA, ModuleB, ModuleD, .... ModuleX], it is uploading the released and the non released ones, whereas the 'non released modules' are declared as 'dependency' in the pom and not as a 'module'.

1/是否有一种避免上载未发布"模块的方法?有没有办法向SCM SVN提供程序注入独家目录"?

1/ IS THERE a way to avoid uploading the 'non released' modules ? Is there a way to inject an 'exlcude directrory list' to SCM svn provider ?

2/一个更广泛的全球性问题，所使用的方法是否正确?还是反模式使用?在这种情况下，应该采取什么替代措施?

2/ A MORE global question, does the approach used is a correct one ? Or is it an anti pattern usage ? In that case, what should be the alternative ?

谢谢.

推荐答案

对我来说，您的方法看起来像是反模式.我建议仅具有要一起发布的相同层次结构中的项目.具有不同发布生命周期的项目应该独立存在-否则您将继续遇到您提到的问题.如果您从根目录(多模块设置)运行发行插件，则该根目录的所有内容都将在SVN中进行标记.

To me, your approach looks like an antipattern. I recommend to only have projects in the same hierarchy that you want to release together. Projects with a different release lifecycle should live on their own - otherwise you will keep running into the issues you mentioned. If you run the release plugin from a root directory (multi-module setup), all of the content of that root directory will be tagged in SVN.

在您的情况下，我可能会创建以下层次结构:

In your case, I would probably create the following hierarchies:

• 核心
• 每种客户类型一个
• 根据您的结构，每个类型可能将它们捆绑在一起(zip)

我将按照您创建发行版的方式对它进行分组.这可能意味着您必须运行发布插件几次，而不是在进行更改时运行一次，例如在Core中使用，但会干净很多.

I would group it by the way you create the release. It might mean that you have to run the release plugin a couple of times instead of just once when you make a change e.g. in Core, but it will be a lot cleaner.

然后，您的打包项目将提取所有依赖项并打包/组装它们.

Your packaging project will then pull in all of the dependencies and package/assemble them.

如果您具有通用的配置选项，建议将它们放入通用的parent pom.不必是您的root(多模块)pom.

If you have common configuration options, I recommend to put them into a common parent pom. This doesn't have to be your root (multi-module) pom.

这篇关于Maven项目设计或反模式设计的好方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！