//maven.apache.org/POM/4.0.0"
xmlns:
xsi="http:
//www.w3.org/2001/XMLSchema-instance"
xsi:
schemaLocation="http:
//maven.apache.org/POM/4.0.0
http:
//maven.apache.org/xsd/maven-4.0.0.xsd">
4.0.0
org.codehaus.mojo
my-project
1.0.SNAPSHOT
#mvn编译命令
mvncompile
---------------------------
[INFO]Nosourcestocompile
[INFO]---------------------------------------------------------------
[INFO]BUILDSUCCESS
[INFO]---------------------------------------------------------------
[INFO]Totaltime:
0.473s
[INFO]Finishedat:
2018-08-05T15:
55:
44+08:
00
[INFO]FinalMemory:
6M/153M
[INFO]---------------------------------------------------------------
请注意，在上述配置和命令当中，我们并没有指定源码文件在哪里？
最后编译到哪里去？
在这里
maven采用了约定的方式从指项目结构中获取源码与资源文件进行编译打包。
a.主源码文件：
${project}/src/main/java
b.主资源文件：
${project}/src/main/resources
c.测试源码文件：
${project}/src/test/java
d.测试资源文件：
${project}/src/test/resources
将java文件移至src/main/java目录，重新执行编译.
mvsrc/hello.java/src/main/java/hello.java
mvncompile;
3、Maven打包
maven打包演示
#mvn打包命令
mvnpackage
4、maven单元测试演示
●编写测试类
●执行测试命令
编译测试类
#创建测试目录
mkdir-p/src/test/java
#编写测试类
vimTestHello.java
#测试类代码------------------------
packagecom.test.tuling;
publicclassTestHello{
publicvoidsayHelloTest（）{
System.out.println（"runtest....."）;
}
}
执行测试指令:
#执行测试
mvntest
执行完指令发现没有执行我们的测试方法，这是为何？
原因在于maven当中的测试类又做了约定，约定必须是Test开头的类名与test开头的方法才会执行。
重新修改方法名后在执行mvntest即可正常执行。
packagecom.test.tuling;
publicclassTestHello{
publicvoidtestsayHelloTest（）{
System.out.println（"runtest....."）;
}
}
通常测试我们是通过junit来编译测试用例，这时就就需添加junit的依赖。
5、maven依赖管理
●在pom文件中添加junit依赖
●修改测试类，加入junit代码
●执行测试命令
加入依懒配置
junit
junit
4.0
test
修改测试类引入junit类.
//引入junit类
importorg.junit.Assert;
importorg.junit.Test;
Assert.assertEquals（"","hi"）;
注意：
当我们在classPath当中加入junit，原来以test开头的方法不会被执行，必须加入@Test注解才能被执行。
提问：
在刚才的演示过程当中，junitjar包在哪里？
是怎么加入到classPath当中去的？
maven是在执行test命令的时间动态从本地仓库中去引入junitjar包，如果找不到就会去远程仓库下载，然后在引入。
默认远程仓库：
默认远程仓库mavencentral其配置在
maven-model-builder-3.2.1.jar\org\apache\maven\model\pom-4.0.0.xml位置
本地仓库位置：
本地仓库位置默认在~/.m2/respository下
要修改${M2_HOME}/conf/settings.xml 来指定仓库目录
--指定本地仓库目录-->
G:
\.m2\repository
maven核心功能总结：
1.maven核心作用是编译、测试、打包。
2.根目录下的pom.xml文件设置分组ID与artifactId。
3.maven基于约定的方式从项目中获取源码与资源文件进行编译打包。
4.对于项目所依懒的组件与会本地仓库引用，如果本地仓库不存在则会从中央仓库下载。
二、maven核心配置
概要：
1.项目依懒（内部、外部）
2.项目聚合与继承
3.项目构建配置
项目依懒
项目依赖是指maven通过依赖传播、依赖优先原则、可选依赖、排除依赖、依赖范围等特性来管理项目ClassPath。
1、依赖传播特性:
我们的项目通常需要依赖第三方组件，而第三方组件又会依赖其它组件遇到这种情况Maven会将依赖网络中的所有节点都会加入ClassPath当中，这就是Maven的依赖传播特性。
⏹举例演示SpringMVC的依赖网络
--添加springwebmvc演示-->
org.springframework
spring-webmvc
4.0.4.RELEASE
在刚刚的演示当中，项目直接依赖了spring-webmvc叫直接依赖，而对commons-logging依赖是通过webmvc传递的所以叫间接依赖。
2、依赖优先原则
基于依赖传播特性，导致整个依赖网络会很复杂，难免会出现相同组件不同版本的情况。
Maven此时会基于依赖优先原则选择其中一个版本。
第一原则：
最短路径优先。
第二原则：
相同路径下配置在前的优先。
⏹第一原则演示
--直接添加commons-logging-->
commons-logging
commons-logging
1.2
上述例子中commons-logging通过spring-webmvc依赖了1.1.3，而项目中直接依赖了1.2，基于最短路径原则项目最终引入的是1.2版本。
⏹第二原则演示：
步骤：
1.添加一个新工程ProjectB
2.配置ProjectB依赖spring-web.3.2.9.RELEASE
3.当前工程直接依赖ProjectB
配置完之后，当前工程projectA有两条路径可以依赖spring-web,选择哪一条就取决于对webmvc和ProjectB的配置先后顺序。
ProjectA==>spring-webmvc.4.0.0.RELEASE==>spring-web.4.0.0.RELEASE
ProjectA==>ProjectB1.0.SNAPSHOT==>spring-web.3.2.9.RELEASE
注意：
在同一pom文件，第二原则不在适应。
如下配置，最终引用的是1.2版本，而不是配置在前面的1.1.1版本.
--在1.2之前添加commons-logging-->
commons-logging
commons-logging
1.1.1
commons-logging
commons-logging
1.2
3、可选依赖
可选依赖表示这个依赖不是必须的。
通过在添 true表示，默认是不可选的。
可选依赖不会被传递。
●演示可选依赖的效果。
4、排除依赖
即排除指定的间接依赖。
通过配置配置排除指定组件。
--排除指定项目-->
org.springframework
spring-web
●演示排除依赖
5、依赖范围
像junit这个组件我们只有在运行测试用例的时候去要用到，这就没有必要在打包的时候把junit.jar包过构建进去，可以通过Mave的依赖范围配置来达到这种目的。
maven总共支持以下四种依赖范围：
compile（默认）:
编译范围，编译和打包都会依赖。
provided：
提供范围，编译时依赖，但不会打包进去。
如：
servlet-api.jar
runtime：
运行时范围，打包时依赖，编译不会。
如：
mysql-connector-java.jar
test：
测试范围，编译运行测试用例依赖，不会打包进去。
如：
junit.jar
system：
表示由系统中CLASSPATH指定。
编译时依赖，不会打包进去。
配合一起使用。
示例：
java.home下的tool.jar
system除了可以用于引入系统classpath中包，也可以用于引入系统非maven收录的第三方Jar，做法是将第三方Jar放置在项目的lib目录下，然后配置相对路径，但因system不会打包进去所以需要配合maven-dependency-plugin插件配合使用。
当然推荐大家还是通过将第三方Jar手动install到仓库。
--system的通常使用方式-->
com.sun
tools
${java.version}
system
true
${java.home}/../lib/tools.jar
--system另外使用方式,将工程内的jar直接引入-->
jsr
jsr
3.5
system
true
${basedir}/lib/jsr305.jar
--通过插件将system的jar打包进去。
-->
org.apache.maven.plugins
maven-dependency-plugin
2.10
copy-dependencies
compile
copy-dependencies
${project.build.directory}/${project.build.finalName}/WEB-INF/lib
system
com.sun
#手动加入本地仓库
mvninstall:
install-file-Dfile=abc_client_v1.20.jar-DgroupId=tuling-DartifactId=tuling-client-Dversion=1.20-Dpackaging=jar
项目聚合与继承
1、聚合
是指将多个模块整合在一起，统一构建，避免一个一个的构建。
聚合需要个父工程，然后使用进行配置其中对应的是子工程的相对路径
tuling-client
tuling-server
⏹演示聚合的配置
2、继承
继承是指子工程直接继承父工程当中的属性、依赖、插件等配置，避免重复配置。
1.属性继承：
2.依赖继承：
3.插件继承：
上面的三个配置子工程都可以进行重写，重写之后以子工程的为准。
3、依赖管理
通过继承的特性，子工程是可以间接依赖父工程的依赖，但多个子工程依赖有时并不一至，这时就可以在父工程中加入声明该功程需要的JAR包，然后在子工程中引入。
<！
--父工程中声明junit4.12-->
junit
junit
4.12
--子工程中引入-->
junit
junit
4、项目属性：
通过配置属性参数，可以简化配置。
--配置proName属性-->
ddd
--引用方式-->
${proName}
maven默认的属性
${basedir}项目根目录
${version}表示项目版本;
${project.basedir}同${basedir};
${project.version}表示项目版本,与${version}相同;
${project.build.directory}构建目录，缺省为target
${project.build.sourceEncoding}表示主源码的编码格式;
${project.build.sourceDirectory}表示主源码路径;
${project.build.finalName}表示输出文件名称;
${project.build.outputDirectory}构建过程输出目录，缺省为target/classes
项目构建配置
1.构建资源配置
2.编译插件
3.profile指定编译环境
构建资源配置
基本配置示例：
package
${basedir}/target2
${artifactId}-${version}
说明：
defaultGoal，执行构建时默认的goal或phase，如jar:
jar或者package等
directory，构建的结果所在的路径，默认为${basedir}/target目录
finalName，构建的最终结果的名字，该名字可能在其他plugin中被改变
配置示例
src/main/java
**/*.MF
**/*.XML
true
src/main/resources
**/*
*
true
说明：
●resources，build过程中涉及的资源文件
¡targetPath，资源文件的目标路径
¡directory，资源文件的路径，默认位于${basedir}/src/main/resources/目录下
¡includes，一组文件名的匹配模式，被匹配的资源文件将被构建过程处理
¡excludes，一组文件名的匹配模式，被匹配的资源文件将被构建过程忽略。
同时被includes和excludes匹配的资源文件，将被忽略。
¡filtering：
默认false，true表示通过参数对资源文件中的${key}在编译时进行动态变更。
替换源可紧-Dkey和pom中的值或 中指定的properties文件。
升级会员 