在微服务项目中，父项目pom文件已经引入了common子模块依赖，在其他业务模块pom文件中为什么还需要引入common子模块依赖

Q：在微服务项目中，父项目pom文件已经引入了common子模块依赖，在其他业务模块pom文件中为什么还需要引入common子模块依赖
A：
在微服务项目中，父项目的POM文件引入了common子模块依赖是为了确保整个项目的依赖关系和模块之间的协调一致性。尽管父项目已经引入了common子模块依赖，但在其他业务模块的POM文件中仍然需要显式地引入common子模块依赖的原因如下：

1. 显式声明模块依赖：每个业务模块都应该明确声明它所依赖的其他模块。通过在业务模块的POM文件中添加对common子模块的依赖声明，可以确保该业务模块正确地依赖并使用common模块中的代码和资源。
2. 版本管理：业务模块可能需要使用不同版本的common模块，或者需要对common模块的依赖进行特定的版本管理。通过在业务模块的POM文件中显式地指定common模块的依赖，可以确保业务模块使用的common模块版本与其它模块保持一致，避免版本冲突或不一致的问题。
3. 细粒度的控制：在某些情况下，业务模块可能只需要使用common模块的部分功能或类，并不需要引入整个common模块的依赖。通过在业务模块的POM文件中明确指定common模块的依赖，可以控制所使用的具体模块和功能，避免不必要的依赖。

总结来说，虽然父项目的POM文件已经引入了common子模块的依赖，但为了确保业务模块的依赖关系和版本管理的一致性，以及细粒度地控制所使用的功能，业务模块的POM文件仍然需要显式地引入common子模块的依赖。

以上为gpt作答。
A：认为gpt作答不满足我，虽然第三点在实际开发中很重要。其实是因为pom.xml中dependencyManagement和dependencies是有区别的。

**1，**<dependencyManagement>**里只是声明依赖，并不实现引入。**
**   因此子项目还需要显示声明需要的依赖，如果不在子项目中声明依赖，是不会从父项目中继承下来的；**
**   只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项。**
**   并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本**
**2，**<dependencies>**实现了引入依赖的jar，注意这里说的**<dependencies>**并不是**<dependencyManagement>**标签下的**<dependencies>
**   子项目默认会依赖父项目中所有声明的**<dependencies>

作者：一叶知秋
链接：https://juejin.cn/post/6869723472075964424
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。