简单来说就是它可以自动的从建构过程的起点一直执行到终点:

① 检查 JAVA_HOME 环境变量

② 解压 Maven 的核心程序
将 apache-maven-3.5.0-bin.zip 解压到一个非中文无空格的目录下。 例如:
D:\Server\apache-maven-3.5.0③ 配置环境变量
M2_HOME:D:\Server\ apache-maven-3.5.0(以自己安装路径的为准)
path:%M2_HOME%\bin 或 D:\Server\ apache-maven-3.5.0\bin


④ 查看 Maven 版本信息验证安装是否正确

⑤ 配置本地仓库
解压目录\ D:\Server\ apache-maven-3.5.0\conf\settings.xml<localRepository>以及准备好的仓库位置</localRepository>
<localRepository>D:/RepMaven</localRepository>
<mirror>
<id>alimaven</id>
<mirrorOf>central</mirrorOf>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
<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 命令时一定要进入 pom.xml 文件所在的目录!
指令 | 描述 |
|---|---|
mvn compile | 编译源代码 |
mvn test-compile | 编译测试代码 |
mvn test | 运行应用程序中的单元测试 |
mvn clean | 清除目标目录中的生成结果 |
mvn site | 生成项目相关信息的网站 |
mvn package | 依据项目生成 jar 文件 |
mvn install | 在本地 Repository 中安装 jar |
mvn idea:idea | 生成 idea 项目 |
mvn archetype:create | 创建 Maven 项目 |
mvn eclipse:eclipse | 生成 eclipse 项目 |
mvn source:jar | 单独打包源码 |
补充:
指令 | 描述 |
|---|---|
mvn clean package | |
mvn clean compile | 清理编译 |
mvn clean test |
Project Object Model:项目对象模型。 将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。 Maven 工程的核心配置。 可以说学习 Maven 就是学习 pom.xml 文件中的配置。
<groupId>com.oy.maven</groupId> <artifactId>Hello</artifactId> <version>0.0.1-SNAPSHOT</version>
com.oy.maven+Hello+0.0.1-SNAPSHOTcom/oy/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar注意:我们自己的 Maven 工程必须执行安装操作才会进入仓库。 安装的命令是: mvn install
当 A jar 包需要用到 B jar 包中的类时,我们就说 A 对 B 有依赖。例如: commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar。通过第二个 Maven 工程我们已经看到, 当前工程会到本地仓库中根据坐标查找它所依赖的 jar 包。配置的基本形式是使用 dependency 标签指定目标 jar 包的坐标。 例如:
<dependencies>
<dependency>
<!—坐标 -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<!-- 依赖的范围 -->
<scope>test</scope>
</dependency>
</dependencies>如果 A 依赖 B, B 依赖 C, 那么 A→B 和 B→C 都是直接依赖,而 A→C 是间接依赖。
① compile
例如: 对 Hello 的依赖。主程序、测试程序和服务器运行时都需要用到。
② test
例如:对 junit 的依赖。仅仅是测试程序部分需要。
③ provided

① 路径最短者优先

② 路径相同时先声明者优先

这里“声明”的先后顺序指的是 dependency 标签配置的先后顺序。
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>Survey160225_4_Environment</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 依赖排除 -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency><properties>
<spring.version>4.1.1.RELEASE</spring.version>
</properties>
....
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>Maven 有三套相互独立的生命周期, 分别是:
再次强调一下它们是相互独立的,你可以仅仅调用 clean 来清理工作目录,仅仅调用 site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
Clean 生命周期一共包含了三个阶段:
此时如果项目需要将各个模块的 junit 版本统一为 4.9, 那么到各个工程中手动修改无疑是非常不可取的。 使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
创建父工程和创建一般的 Java 工程操作一致,唯一需要注意的是: 打包方式处要设置为 pom。
.........从当前目录到父项目的 pom.xml 文件的相对路径
代码示例:
<parent>
<groupId>com.oy.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 指定从当前子工程的 pom.xml 文件出发,查找父工程的 pom.xml 的路径 -->
<relativePath>../Parent/pom.xml</relativePath>
</parent>此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。
将 Parent 项目中的 dependencies 标签,用 dependencyManagement 标签括起来
junitjunit4.9test
在子项目中重新指定需要的依赖,删除范围和版本号
junit junit
将多个工程拆分为模块后, 需要手动逐个安装到仓库后依赖才能够生效。 修改源码后也需要逐个手动进行 clean 操作。 而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。
在总的聚合工程中使用 modules/module 标签组合, 指定模块工程的相对路径即可
<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>