phpstudy集成环境

 首页 > 实在受不了了，问一个maven父pom的版本更新问题！

实在受不了了，问一个maven父pom的版本更新问题！

由于新项目使用为微服务的架构，所以为了方便版本的管理
独立了一个pom的父项目，存储公用的properties，和各个服务对应的版本。
项目使用的是dubbo做soa
例如我的项目叫xbx
那么项目的结构就是
xbx-parent
xbx-facade-user //存放接口
xbx-service-user //提供服务

那么parent的pom里面就有

<groupId>com.xbx</groupId>
<artifactId>xbx-parent</artifactId>
<version>0.0.1</version>
<packing>pom</packing>

<properties>
    <xbx-facade-user.version>0.0.1</xbx-facade-user.version>
    <!--等等其他很多依赖-->
</properties>

那么问题来了，当我xbx-facade-user更新的时候，对应的parent中的properties需要更新，parent的版本就需要更新。

那么！所有依赖这个parent的项目都需要更新！！！
十分麻烦！！！
有什么简便的方法吗！！！

已经尝试的方法有
1、在父项目使用properties标识父项目的版本

结论： 不可行，在私有库中如果用properties的话properties不是要从parent里面继承才方便吗？但是properties在parent的话我怎么定位是哪一个版本的parent呢

2、使用mvn versions批量更新

结论： 不可行，为什么呢？因为这个方式貌似只适合有层级结构的项目，例如
Project
--SubProject1
  --pom.xml
--SubProject2
  --pom.xml
pom.xml

我想一定有其他办法的，各位大神行行好告诉我呗（感谢感谢）

抱歉，我用gradle的

将parent，child的版本保持一致就行了。没有必要在parent里写child的版本
<xbx-facade-user.version>0.0.1</xbx-facade-user.version>

比如parent是0.0.1，那么child的pom里这样写：

<parent>
  <groupId>com.xbx</groupId>
  <artifactId>xbx-parent</artifactId>
  <version>0.0.1</version>
  <packing>pom</packing>
</parent>

<groupId>com.xbx</groupId>
<artifactId>xbx-facade-user</artifactId>
<packing>jar</packing>
<parent>
  <groupId>com.xbx</groupId>
  <artifactId>xbx-parent</artifactId>
  <version>0.0.1</version>
  <packing>pom</packing>
</parent>

<groupId>com.xbx</groupId>
<artifactId>xbx-service-user</artifactId>
<packing>jar</packing>

<dependencies>
  <dependency>
    <groupId>com.xbx</groupId>
    <artifactId>xbx-service-user</artifactId>
    <version>${project.version}</version>
  </dependency>
</dependencies>

可以使用dependencymanager来处理，把dm package为pom，然后import pom来处理

这就是 Maven 的特性。
你的项目目录既然没有层级关系，那我可以理解你的 parent 项目其实是一个 master。
看一下 Apache Master POM 的配置里面都有些什么吧

我实在看不出来，你把一个变动非常频繁的变量提取到一个没有目录关系的 pom 文件中去的意义。

你的做法已经无法在找到现有的插件来帮助你完成这个功能了，这是多么的有个性。多研究一下开源的示例吧。看看别人的 Maven 用法。即便是更换像 Gradle 这样的构建工具他也是有目录层级关系的。同样不满足你的要求。

parent的pom.xml下添加依赖包括版本号

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.test</groupId>
            <artifactId>test-api</artifactId>
            <version>1.0-test</version>
        </dependency>
    <dependencies>
<dependencyManagement>

子项目的pom.xml，添加依赖无需版本号，默认使用父pom的依赖，也可以单独指定版本

<dependencies>
    <dependency>
        <groupId>com.test</groupId>
        <artifactId>test-api</artifactId>
    </dependency>
<dependencies>

基本理解题主的意思了，如果你是开发阶段，大家都用snapshot版本好了，永远只拿最新开发版本，等到稳定了，就用版本号，但理论上这个版本号的升级不会太频繁，等到下一个开发阶段，继续用snapshot然后稳定版本号。以此循环下去，这才是maven开发的逻辑

另外你每个项目的版本号没必要写在一个共有的地方，比如A它用的是B的1.0，现在B升级到1.1了，A可不一定要跟进这个升级的，因为A相应的改动可能没准备好。你写在一个共有的地方，大家一升都升相当不灵活。每个服务维护自己依赖库的版本就好

题外话：这个不叫微服务，说到底还是传统的多module开发，只不过互相之间的调用是走远程的而已。每个服务有两份东西，一个服务端，一个库，库是给其他要依赖这个服务的服务们用的。但这个库会不时的更新，导致其他依赖的服务也需要不停的更新，重新编译和发布。

真正的微服务，理论应该一个服务一个repo，没有库这种文件上的依赖，互相之间的调用走纯的RESTful API。也就是说服务之间的依赖仅仅是一纸契约，而这个契约的改动是很不频繁的。例如服务A、B，B依赖A。A是不需要提供库的，当B需要使用A的接口时，它可以直接调用RESTful API，也可以把这个REST API封装成某个库，但这也只是发生在A这一测。这样的好处是：

回到题主这个问题，其实归根到底是dubbo造成的，dubbo这种就不是真正意义上的微服务，服务与服务之间存在代码依赖，绑的很死。所以dandang扩展的dubbox一个主要改变就是支持REST，把这种代码级别的依赖打破。

【热门文章】
【热门文章】