1.JavaEE开发构建工具历史走向
自动化构建工具
Make> Ant> Maven >Gradle
2.构建的概念和环节
Java必须经过编译得到.class文件
清理:删除以前编译结果,为重新编译做好准备
编译:JAVA编译为字节码文件
测试:关键点测试
报告:,展示测试结果
打包:java含诸多文件的工程封装为一个压缩文件,对应jar包 Web对应War包
安装:将Maven环境下打包的jar包或War包安装到本地仓库中
部署:打包结果部署到远程仓库或服务器上运行
编译打包部署测试自动化完成,程序化解决重复工作,只需要编码
3.Jar包之间的冲突处理
jar包不足项目无法正常工作，但其实有的时候jar包多了项目仍然无法正常工作，这就是jar包之间的冲突。
使用Maven就可以自动的处理jar包之间的冲突问题。因为Maven中内置了两条依赖原则：
最短路径者优先和先声明者优先.
4.安装与配置设置
检查JAVA_HOME环境变量。Maven是使用Java开发的，所以必须知道当前系统环境中JDK的安装目录。
解压Maven的核心程序。将apache-maven-3.5.4-bin.zip解压到一个非中文无空格的目录下。
在系统变量里面创建M2_HOME变量，并赋值
在Path变量中，添加maven环境变量
查看Maven版本信息验证安装是否正确,打开cmd输入:mvn -v
本地仓库地址更改
Maven的核心配置文件位置：
apache-maven-3.5.4confsettings.xml
修改配置文件
<localRepository>自设本地仓库路劲</localRepository>
配置阿里云镜像（下载速度快）
<mirror>
<id>nexus-aliyun</id>
<mirrorOf>central</mirrorOf>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
Maven编译版本
settings.xml中的<profiles></profiles>标签中加入如下内容
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
Maven打包插件
Maven本身的打包插件不负责将依赖的jar包一并打入到jar包中。
所以在pom.xml中加入如下内容:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<!-- 指定主类 -->
<mainClass>xxx.xxx.XXX</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
第4章 Maven核心概念
Maven的核心概念包括：POM、约定的目录结构、坐标、依赖、仓库、生命周期、插件和目标、继承、聚合。
Project Object Model：项目对象模型。
开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。
Maven的坐标
使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。
（1）groupId：公司或组织的域名倒序+当前项目名称
（2）artifactId：当前项目的模块名称
（3）version：当前模块的版本
本地仓库:
任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行。
4.5 依赖管理
基本概念
当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。
直接依赖和间接依赖
如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。
4.5.1 依赖的范围
1）compile（默认就是这个范围）
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。
2）test
（1）main目录下的Java代码不能访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：对junit的依赖。仅仅是测试程序部分需要。
3）provided
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。
4）其他：runtime、import、system等。
4.5.2 依赖的传递性
当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如：
|
Maven工程 |
依赖范围 |
对A的可见性 |
||
|
A |
B |
C |
compile |
√ |
|
D |
test |
× |
||
|
E |
provided |
× |
||
4.5.4 依赖的排除
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>OurFriends</artifactId>
<version>1.0-SNAPSHOT</version>
<!--依赖排除-->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.2</version>
</dependency>
4.5.5 统一管理目标Jar包的版本
统一配置的方式：
|
<!--统一管理当前模块的jar包的版本-->
|
|
…… |
|
<dependency> |
这样一来，进行版本调整的时候只改一改地方就行了。
5.1 为什么需要继承机制
由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。
使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
父工程的打包方式为pom（只用于配置的管理，不写任何代码）
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
父工程只需要保留pom.xml文件即可
5.3 在子工程中引用父工程
<parent>
<!-- 父工程坐标 -->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
<relativePath>..</relativePath>
</parent>
|
<!--继承--> <!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径--> </parent> |
此时如果子工程的groupId和version如果和父工程重复则可以删除。
5.4 在父工程中管理依赖
将Parent项目中的dependencies标签，用dependencyManagement标签括起来
|
<!--依赖管理--> |
在子项目中重新指定需要的依赖，删除范围和版本号
|
<dependency> |
第6章 聚合
6.1 为什么要使用聚合？
将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装、清理工作。
6.2 如何配置聚合？
在总的聚合工程中使用modules/module标签组合，指定模块工程的相对路径即可
|
<!--聚合--> |
Maven可以根据各个模块的继承和依赖关系自动选择安装的顺序
第7章 通过Maven创建Web工程
创建简单的Maven工程，打包方式为war包
点击Project Structure,
选择对应的Module，添加web目录,
在web目录下创建index.jsp页面
部署到Tomcat上运行
第8章 Maven酷站
我们可以到http://mvnrepository.com/搜索需要的jar包的依赖信息。
http://search.maven.org/
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
