Maven的一个核心作用就是管理项目的依赖,这个依赖就可以理解成jar包。
有了它就不用再去网上一个一个找jar包了,直接添加jar包的坐标就好。
那么其具体如何导入呢?一、依赖管理在maven工程中,有一个核心配置文件pom.xml,在该配置文件中即可以引入依赖。
1本地仓库引入<dependencies>标签就好比以前的lib包,<dependencie>标签也就对应着jar包。
其中关于标签名:groupId:定义当前项目(jar包)隶属的实际项目组。
artifactId:定义当前项目(jar包)的名称。
version:定义当前项目(jar包)的版本号。
正是因为有了version这个标签的存在,通过该标签统一版本起来也方便了很多。
因为这两种依赖很常见,我本地仓库中已经有了,所以导入依赖时根据提示就可以导入。
此外在开发工具中也可以直接搜索依赖:使用快捷键:Alt+Insert,可以搜索对应的依赖,点击即可以引入依赖。
不过上述这两种情况,都是本地仓库中存在对应的依赖才能够被搜索到。
如果本地仓库没有,就需要使用到私服了。
2私服引入昨天在配置文件夹中就配置过对应的私服。
使用的是阿里云私服,将其路径复制下来访问,可以访问到如下界面:通过文件搜索功能可以搜索到需要的依赖,比如我这边搜索的是druid。
找到对应的jar包点击,可以下载对应的jar包,但是如果是使用maven,不用下载。
将依赖复制后在项目中引入即可。
在引入依赖后开发工具右下角会出现如下提示:点击import Changes就完成依赖的引入了。
同时也会将该依赖下载到本地仓库中。
二、依赖配置在引入需要使用的依赖后,有时候不能直接就使用当前的依赖,需要对这些依赖进行配置。
1依赖范围设置maven的运行环境有三种:编译classpath,测试classpath,运行classpath。
而依赖范围设置就是用来控制依赖与这三种classpath之间的关系的。
其中依赖范围都是在标签<scope>中配置:①编译依赖范围compile如果没有指定,默认就是这种依赖范围。
使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。
典型的例子就是jdbcTemplate,它在编译、测试和运行代码时都需要。
②测试依赖范围test使用此依赖范围的Maven依赖,只对测试classpath有效。
在编译和运行项目期间都不需要使用此依赖。
典型的例子就是Junit,它只在测试代码时有效。
③已提供依赖范围:provided使用此依赖范围的maven依赖在编译和测试classpath有效,但运行时无效。
典型的例子就是servlet-api。
编译和测试的时候需要使用servlet-api中的方法,但是使用tomcat运行项目的时候不需要。
我们查看下Tomcat的文件路径,会发现其本身就自带了该jar包。
所以Tomcat在运行期间会自动提供这个依赖。
如果我们引入的该依赖在运行时也有效,一旦和Tomcat自带的版本不一样,就会出现冲突。
④运行时依赖范围:runtime使用此依赖范围的maven依赖对于测试和运行classpath有效,但在编译时无效。
典型的例子是JDBC驱动实现。
项目中只有在执行测试或者运行项目的时候才需要该依赖。
⑤系统依赖范围:system该依赖和provided依赖范围完全一致。
但是此依赖不是来自Maven的中央仓库。
使用system范围的依赖时必须通过<systemPath>标签指定依赖文件的路径。
典型的例子是Oracle的驱动包。
该依赖从中央仓库无法下载,需要先将Oracle的驱动包下载到本地,再通过本地路径引入。
该依赖范围了解即可,使用不常见。
注意:上述编译都是指对项目主代码的编译,不包含对于测试代码的编译。
2依赖版本维护事实上,在一个项目中,需要引入的依赖是很多的,可能有几十个。
而各个依赖又有不同的版本,为了统一维护版本,可以专门将依赖的版本抽取出来统一管理:在<properties>标签中放入各个依赖的版本号。
版本标签命名格式为依赖名.version。
在对应的依赖<version>中使用${}引入前面定义好的版本即可。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)