父pom和微服务
- 我们有几个微服务项目，每个项目都是独立的（在单独的Spring引导服务器上运行，公开rest服务，使用单独的DB模式…）
- 我们使用maven来管理依赖项。
让父pom将每个微服务声明为模块是一个好主意吗？ 所以有助于管理公共依赖项（比如每个项目中都使用了lib servlet-api，删除所有项目并仅在父pom中声明它）
多模块父pom的“问题”是，没有复杂的配置文件，它会将模块锁定在同一个发布周期中（假设您正在使用Release Plugin ，您应该这样做）。
我使用Maven的方式是让父pom声明：
- 公共依赖项（日志API，JUnit等）。
- 常见的插件。
-
dependencyManagement部分中的所有依赖项。 -
pluginManagement部分中的所有插件。
每个模块都将父pom作为其父级，但父级对模块一无所知。
这样做的好处来自上面的最后两个子弹，即“管理”部分。 “管理”部分中包含的任何内容都需要在想要使用特定依赖项或插件的模块中重新声明。
例如，父级可能如下所示：
com.example parent 1.0.00-SNAPSHOT ... org.slf4j slf4j-api 1.7.7 junit junit 4.11 test commons-lang commons-lang 2.6 commons-collections commons-collections 2.1 org.apache.maven.plugins maven-compiler-plugin 3.1 1.8 org.apache.maven.plugins maven-assembly-plugin 2.4 false src/main/assembly/assembly.xml make-assembly package single
模块可能如下所示：
com.example parent 1.0.00-SNAPSHOT com.example module 1.0.00-SNAPSHOT commons-lang commons-lang org.apache.maven.plugins maven-assembly-plugin
该模块将：
- 依赖于
org.slf4j:slf4j-api:1.7.7:compile，junit:junit:4.11:test和commons-lang:commons-lang:2.6:compile。 - 有插件
org.apache.maven.plugins:maven-assembly-plugin:2.4
我会避免父pom中的依赖。 如果你的（独立）微服务之一需要其他一些东西，那就太尴尬了。 让父母知道每个微服务是很奇怪的。
如果需要，您可以坚持使用dependencyManagement建议默认版本/范围。 除此之外，父pom非常便于定义插件，存储库等。
相反，我会将一组共同的依赖项组合到一个特定的工件中，这些工件可能只是一个具有依赖关系的pom。 然后你可以依赖，比如说“com.example / common-db-dependencies / 1.2”来包含一组标准的数据库依赖项，比如hibernate，apache derby和JPA specs。 （或者你正在使用的任何东西）。 服务不使用JPA / SQL可以避免所有依赖。
不要纠缠自己。 如果你试图覆盖每个案例，那么过度依赖结构很容易。 因此，只尝试标准化大多数服务真正使用的东西。
这里有依赖和依赖管理的一个问题。 假设您的一个微服务因为某些原因想要升级到更新版本的公共…你不能这样做，因为你有父母。 我确实理解减少插件配置等冗余重复的诱惑。 在微服务中，我们需要更多地考虑每项服务的独立性。
一些配置如说您的存储库或发布配置等可能很常见。