让父pom将每个微服务声明为模块是个好主意吗?因此有助于管理公共依赖项(就像每个项目中使用的lib servlet-api女巫一样,将其全部删除并仅在父pom中声明它)
我肯定会使用父项目。
我已经在这两个机构工作多年了。。。微服务与否、模块化与否、Ant、Maven和Gradle。。
我们需要理解,使用父pom并不意味着谈论不耦合和独立的微服务:
我听说“一个微服务可能需要为一个依赖项使用不同的版本”,你可以,只要覆盖特定微服务pom中的依赖项。
我们需要关注“这里有什么好处,有什么坏处”:
还有更多:
犯人呢?目前我没有看到任何异常,因为可以通过覆盖特定微服务pom中的常见行为来管理异常,我仍然可以隔离管理任何事情(独立构建、独立发布、独立部署..)没有耦合
目前还不确定我们所说的“它将模块锁定在同一发布周期”是什么意思。事实并非如此,除非您使用外部快照,否则我可以使用相同的父版本单独发布微服务。
例如,我可以让模块1声明父1.0并独立发布,而无需从父级运行发布过程,我可以直接在子模块上运行它,但我不需要在子模块项目中声明任何外部SNAPSHOT(无论是否有父级,您都会遇到同样的问题)
我会避免父pom中的依赖项。如果您的一个(独立)微服务想要其他东西,这很尴尬。让父知道每个微服务很奇怪。
不过,如果需要,您可以坚持使用dependencyManagement来建议默认版本/范围。父pom对于定义插件、存储库等非常方便。
相反,我会将一组常见的依赖项分组到一个特定的工件中,这可能只是一个具有依赖项的pom。然后您可以依靠,比如“com.example/common-db-dependencies/1.2”来包含一组标准的数据库依赖项,如hibernate、apache derby和JPA规范。(或者您正在使用的任何东西)。一个服务不使用JPA/SQL可以一起避免这种依赖。
但是不要纠缠自己。如果您试图涵盖每个案例,很容易过度使用依赖结构。所以,只尝试标准化真正被大多数服务使用的东西。
多模块父pom的“问题”是,如果没有复杂的配置文件,它会在相同的发布周期中锁定模块(假设您使用的是发布插件,您应该使用)。
我与Maven合作的方式是让父pom声明:
依赖项管理
部分中的所有依赖项
pluginManagement
部分中的所有插件
每个模块都将父pom视为其父模块,但父模块对这些模块一无所知。
这样做的好处来自上面最后两个项目,即“管理”部分。“管理”部分中包含的任何内容都需要在希望使用特定依赖项或插件的模块中重新声明。
例如,父对象可能如下所示:
<project>
<groupId>com.example</groupId>
<artifactId>parent</artifactId>
<version>1.0.00-SNAPSHOT</version>
...
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>2.1</version>
</dependency>
</dependencyManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</project>
模块可能是这样的:
<project>
<parent>
<groupId>com.example</groupId>
<artifactId>parent</artifactId>
<version>1.0.00-SNAPSHOT</version>
</parent>
<groupId>com.example</groupId>
<artifactId>module</artifactId>
<version>1.0.00-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
</dependency>
</dependencies>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
</plugins>
</project>
该模块将:
org。slf4j:slf4j api:1.7.7:compile
,junit:junit:4.11:test
和commons-lang:commons-lang:2.6:compile
org。阿帕奇。专家插件:maven汇编插件:2.4
问题内容: 我们有几个微服务项目,每个项目都是独立的(在单独的spring boot服务器上运行,公开其余服务,使用单独的DB模式…) 我们使用Maven管理依赖关系。 有一个父pom将每个微服务声明为模块是一个好主意吗?因此,有助于管理公共依赖项(例如,在每个项目中都使用lib servlet-api witch,将其全部删除并仅在父pom中声明) 问题答案: 多模块父pom的“问题”是,没有复
当我使用mvn install构建工件时,我看到JAR在我的.m2文件夹中构建,但是Project.version没有替换为实际版本,即1.0-Snapshot。 > 每个工件的.m2存储库中的父pom和/或子pom是否具有指定的版本,或者是否为Project.version 我是否应该在父POM中指定Project.Version作为属性。maven文档说明Project.version可由De
是否有一个具体的推荐方法将spring启动的父pom包含到已经有一个必需的父pom的项目中? 对于需要从组织父级扩展的项目,您有什么建议(这是非常常见的,甚至是许多/大多数项目发布到Maven central,这取决于它们来自的feeder Repo)。大部分构建内容都与创建可执行JAR相关(例如,运行嵌入式Tomcat/Jetty)。有一些方法可以对事物进行结构化,这样您就可以获得所有的依赖关系
我正试着做一个包含所有项目的胖uber罐子。如果我做了“MVN包”,我得到一个uber jar下的“blah”项目标签文件夹。(blah项目有主类。)uber jar包含所有项目(作为文件夹而不是jar),但当我运行它时,它似乎无法识别feature1和feature2项目。 我在上面添加了feature1和feature2的依赖项,以便它们在uber jar文件中。这错了吗?附注。blahmes
使用可以用于基于的遗留用例,但也可以测试我们正在迁移的未来用例:。 我是否可以在每次修改POM时实现以下反应器构建?或者,类似的东西?或者,Maven仅仅是这个用例的错误工具吗? 理想情况下,我希望在一个反应器构建中实现所有功能,每个编译并与每个继承的依赖项一起使用。我知道这会使我的Maven repo处于不希望的状态,但至少我可以将反应器构建插入到我的CI,并确保我的构建在依赖平台上运行。 注意
我想知道每种方法的利弊是什么。例如,在graphQL中包含所有内容似乎有点多余,因为我们将在每个服务中复制模式的部分。另一方面,我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗?我们都没有使用GraphQL的经验,所以这里是否有一些明显的利弊我们可能会遗漏? 提前道谢!