父pom的dependencyManagement的作用

maven 是用来构建项目结构的,是一种主流的项目构建工具,项目中使用到的第三方jar包,用maven来管理是非常方便的,本篇文章主要来讲解<dependencyManagement> 和 <dependencies> 在管理jar包方面的不同之处,对于maven的基础信息和其他的一些方面不再做介绍。

现在的项目基本上都是使用多module来管理的,这就涉及到一个问题,多module之间如何使用共同的第三方jar,或者说如何减少相同的jar导入的配置。

1. 首先介绍<dependencies>

   我们是这里引入了一个jar包之后,这里如果没有加上version版本号的话,那么maven就会去<dependencyManagement>里找对应groupId和artifactId的jar,如果有就继承他,如果没有就会报错,这时候其实在我们配置的本地仓库中会真实的下载对应的jar包,这时候所有的子module都会默认继承这里面所有声明的jar

2. <dependencyManagement>

    这里其实是起到管理依赖jar版本号的作用,一般只会在项目的最顶层的pom.xml中使用到,所有子module如果想要使用到这里面声明的jar,只需要在子module中添加相应的groupId和artifactId即可,并不需要声明版本号,需要注意的是这里面只是声明一个依赖,并不是真实的下载jar,只有在子module中使用到,才会去下载依赖。
 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
类似JDepend的工具,特征如下: 1)、根据您对系统架构约束的定义,时刻监视真实系统的不一致,在每次构建(将来,我会考虑改为每次编译时)时直接告诉你问题的细节,大大提高你定位问题的效率; 2)、您可以只定义"允许"的规则,也可以只定义"不允许"的规则,是的,因为我发现别的工具只能定义架构“是什么”约束,而不能设定“不是什么”约束,所以才有了这样的改进,对了,这些规则可以是组件级别的,也可以是包级别的,而不少类似工具只是简单地对自然包进行分析,事实上,有些自然包的划分仅仅是出于概念的清晰性而建立的,并不是出于设计影响的目的,对于这样的包,我们难以对它有太多苛求,只有在"组件"级别上,才有必要认真考虑它们之间依赖的设计影响,所以,JDM的不同之处就在于它更人性化地把管理粒度的重点从包转移到了组件—— 一个可以自由定义大小的概念上,使得您可以将概念划分和设计影响“解耦合”。 3)、它很人性化,您可以自定义各种规则不符合到什么程度才是您不可接受的,哦,这也是很多类似工具做得不够的地方,我不用再被迫一刀切地僵化地使用工具了,我可以很方便地定义不同局部的质量要求,可以方便地定义它们不同的警报级别,还可以定义不同问题输出信息的程度——您可不想被一大堆无用的信息淹没,对吧? 4)、它确实有点power,真的,我自己以前用的工具只会告诉我结果,而难以把问题的究竟给我解释清楚,现在它不仅会告诉我哪里出问题了,还能给出内部的详细分析信息,例如:出现了组件之间的循环依赖,它不是简单地告诉我哪些组件存在循环依赖,而是会告诉我这些循环依赖路径有几条,分别是什么,还会告诉我一个环的每段组件依赖内部是由哪些包依赖甚至类依赖构成的,这些详细信息能够大大提高你定位问题的效率,您可以将它直接作为单元测试运行,如果将它加入持续集成冒烟测试,失败的架构验证能够使得构建失败,保证不符合质量的设计不会被打包和发布;

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值