昨天下载并配置了maven，今天就实际操作下。
Maven的一个核心作用就是管理项目的依赖，这个依赖就可以理解成jar包。
有了它就不用再去网上一个一个找jar包了，直接添加jar包的坐标就好。
那么其具体如何导入呢？
在maven工程中，有一个核心配置文件pom.xml，在该配置文件中即可以引入依赖。
1本地仓库引入
<dependencies>标签就好比以前的lib包，<dependencie>标签也就对应着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>中使用${}引入前面定义好的版本即可。
关注微信