有一个父pom将每个微服务声明为模块是一个好主意吗?因此,有助于管理公共依赖项(例如,在每个项目中都使用lib servlet-api
witch,将其全部删除并仅在父pom中声明)
多模块父pom的“问题”是,没有复杂的配置文件,它将模块锁定在相同的发布周期中(假设您使用的是Release
Plugin
)。
我使用Maven的方式是让一个父pom声明:
dependencyManagement
节中的所有依赖项。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.apache.maven.plugins:maven-assembly-plugin:2.4
我们有几个项目是微服务,每个项目都是独立的(在单独的spring boot服务器上运行,公开rest服务,使用单独的DB模式…) 我们使用maven来管理依赖关系 让父pom将每个微服务声明为模块是个好主意吗?因此有助于管理公共依赖项(就像每个项目中使用的lib servlet-api女巫一样,将其全部删除并仅在父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的经验,所以这里是否有一些明显的利弊我们可能会遗漏? 提前道谢!