먼저, 보다 정확한 Maven 응용 시나리오를 빠르게 구축할 수 있도록 Maven의 개념을 빠르게 정리하겠습니다.
Maven은 ant도 아니고 make도 아닙니다. 이전에 노출된 빌드 도구의 경우 다음과 같은 몇 가지 세부 단계를 작성해야 합니다. compile project1/src/*.java 및 기타 비슷한 진술.
Maven은 "구성보다 관례" 방식을 채택합니다. 개발을 위한 몇 가지 일반적인 작업과 단계가 Maven에서 구체화되었으므로 사용자는 더 이상 이러한 명령문을 작성할 필요가 없습니다.
Maven에는 개발 프로세스에 대한 지원이 내장되어 있으며, 컴파일뿐만 아니라 패키징 및 게시도 가능하며 이러한 모든 단계를 한 번에 완료할 수도 있습니다.
Maven은 Ivy가 아닙니다. 종속성 관리는 Maven의 기능 중 하나입니다. Maven은 종속성 관계에 범위 개념을 추가하여 종속성 관계 구분을 더욱 구체화합니다.
Maven은 프로젝트 관리 도구로 자리매김합니다. 프로젝트 개발 과정의 거의 모든 것을 관리하는 역할을 담당합니다.
a. 버전: maven에는 자체 버전 정의 및 규칙이 있습니다.
b. 빌드: maven은 다양한 애플리케이션 유형을 지원하며, 지원되는 각 애플리케이션 유형이 정의됩니다. 빌드 규칙 및 도구 세트;
c. 출력 관리: maven은 프로젝트에서 빌드한 제품을 관리하고 사용자 라이브러리에 추가할 수 있습니다. 이 기능은 프로젝트 팀과 다른 부서 간의 전달 동작에 사용될 수 있습니다.
d. 종속성: Maven은 개발 프로세스 중 종속성 혼란과 상호 오염을 피하기 위해 종속성 특성을 자세히 분석하고 구분합니다.
e. 문서화 및 빌드 결과: maven의 사이트 명령은 빌드 프로세스, javadoc, 제품 문서 등의 다양한 출력을 포함하여 다양한 문서 정보 공개를 지원합니다.
f. 대형 프로젝트는 일반적으로 Maven으로 쉽게 관리할 수 있는 여러 개의 작은 프로젝트 또는 모듈로 구성됩니다.
h. 이식성 관리: maven은 다양한 개발 시나리오에 대해 다양한 유형의 출력 결과를 출력할 수 있습니다. . Maven 라이프 사이클
Maven은 프로젝트 구성을 검증, 컴파일, 테스트, 패키징 및 배포를 포함한 다양한 라이프 사이클(라이프사이클)로 나눕니다. 
Maven의 모든 실행 작업(목표)은 프로세스에서 실행 위치를 표시해야 합니다. 그러면 Maven이 실행될 때 프로세스 개발에 따라 다양한 처리를 위해 이러한 목표가 순차적으로 호출됩니다. 이는 Maven의 기본 스케줄링 메커니즘이기도 합니다. 일반적으로 후속 프로세스는 이전 프로세스에 따라 달라집니다.
물론 Maven은 사용자 요구 사항에 따라 특정 단계를 건너뛸 수 있는 구성 파일도 제공합니다.
03.maven "구성에 대한 규칙"
그러나 사용자는 필요한 경우가 아니면 동의한 내용을 수정할 필요가 없습니다.
Maven의 기본 파일 저장 구조는 다음과 같습니다.
/Project 디렉터리 pom.xml maven 구성 파일
/src 소스 코드 디렉터리
/src/main 프로젝트 소스 코드 디렉터리
/src/main/java 프로젝트 Java 소스 코드 디렉터리
/src/main/resource 프로젝트 리소스 디렉터리
/src/test 유닛 테스트 디렉터리
/src/test/java
/target 출력 디렉터리, 모든 출력은 이 디렉터리에 저장됩니다.
/target/classes 컴파일된 클래스 파일
각 단계에 대해 모두가 자신의 작업을 수행하는 방법을 알고 있습니다. 바르게.
예를 들어, 컴파일 작업은 src/main/java의 모든 Java 파일을 컴파일하고 해당 출력 클래스 파일을 target/classes에 저장하는 방법을 알고 있습니다.
"구성보다 관례" 전략을 채택하면 구성 수정 작업량을 줄이고 학습 비용을 줄일 수 있습니다. 더 중요한 것은 프로젝트에 통일된 사양을 도입한다는 것입니다.
<groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.3.7.RELEASE</version>
Maven은 4가지 요소를 사용하여 특정 출력을 고유하게 찾습니다: groupId:artifactId:packaging:version. org.springframework:spring:2.5와 같은 것입니다.
groupId 그룹, 회사, 그룹, 조직, 프로젝트 또는 기타 그룹입니다. 그룹 ID의 규칙은 프로젝트를 생성한 조직의 역방향 도메인 이름으로 시작한다는 것입니다.
ArtifactId groupId 아래는 개별 프로젝트의 고유 식별자를 나타냅니다. 예를 들어 Tomcat, Commons 등이 있습니다. ArtifactId에는 마침표(.)를 포함하지 마세요.
버전 프로젝트의 특정 버전입니다. 릴리스 프로젝트에는 프로젝트의 특정 버전을 가리키는 고정 버전 식별자가 있습니다.
프로젝트의 패키징 형식도 Maven 좌표의 중요한 부분이지만 프로젝트의 고유 식별자에는 포함되지 않습니다.
프로젝트의 groupId:artifactId:version은 이를 고유한 프로젝트로 만듭니다. 동일한 그룹 ID, 이슈 ID, 버전 식별을 동시에 갖는 프로젝트를 가질 수 없습니다.
Packaging 프로젝트 유형, 기본값은 jar이며, 이는 패키징 후 프로젝트의 출력을 설명합니다.
maven은 버전 관리 중에 SNAPSHOT , LATEST , RELEASE 등 여러 특수 문자열을 사용할 수 있습니다.
"1.0-SNAPSHOT"과 같은 것입니다. 각 부분의 의미와 처리 논리는 다음과 같이 설명됩니다.
SNAPSHOT: 은 개발 프로세스에서 기호를 날짜 및 시간 값으로 확장하고 설치 또는 게시 시 이를 UTC로 변환합니다. 이 구성 요소 시간.
예를 들어 "1.0-SNAPSHOT"은 2010년 5월 5일 오후 2시 10분에 출시되면 1.0-20100505-141000-1이 됩니다.
최신: 은 특정 구성 요소의 최신 릴리스를 나타냅니다. 이 릴리스는 마지막 시간에 따라 릴리스 버전일 수도 있고 스냅샷 버전일 수도 있습니다.
릴리스: 는 마지막 릴리스 버전을 나타냅니다.
개인적으로 종속성 관리는 Maven에서 가장 매력적인 기능이라고 생각합니다. 이 기능을 사용하면 개발자는 코드의 직접적인 종속성에만 집중할 수 있습니다.
예를 들어, 스프링을 사용하는 경우 스프링 종속성 설명을 추가하면 스프링 자체가 의존하는 외부 항목에 대해 maven이 도움을 줄 수 있습니다.
모든 외부 종속성 설명에는 groupId, ArtifactId, 버전, 범위, 유형, 선택 요소가 포함됩니다. 처음 세 개는 필수이며 각각의 의미는 다음과 같습니다.
여기서 버전은 간격 표현식으로 표현될 수 있습니다. 예를 들어 (2.0,)은 >2.0을 의미하고, [2.0,3.0)은 2.0<=ver<를 의미합니다. ;3.0 ; [1,3),[5,7]과 같이 여러 조건을 쉼표로 구분합니다.
Maven은 프로그램의 외부 종속성이 프로그램의 단계 및 애플리케이션 시나리오에 따라 변경될 것이라고 믿기 때문에 Maven의 종속성은 범위에 따라 제한됩니다.
범위에는 다음 값이 포함됩니다.
컴파일(컴파일 범위) ---> compile은 모든 클래스 경로에서 사용할 수 있으며 패키지화됩니다.
제공된 (제공된 범위) ---> 제공된 종속성은 JDK 또는 컨테이너가 종속성을 제공한 경우에만 사용됩니다.
예를 들어, 웹 애플리케이션을 개발하는 경우 서블릿을 컴파일하려면 컴파일 클래스 경로에서 사용 가능한 Servlet API가 필요하지만 패키지된 WAR에 이 Servlet API를 포함하고 싶지는 않습니다.
runtime（运行时范围 --> runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。
比如你可能在编译的时候只需要 JDBC API JAR，而只有在运行的时候才需要 JDBC 驱动实现。
test（测试范围）--> test 范围依赖 在一般的 编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。
system（系统范围） --> system 范围依赖与 provided 类似，但是你必须显式的提供一个对于本地系统中 JAR 文件的路径。
<dependency> <groupId>org.wltea</groupId> <artifactId>analyzer</artifactId> <version>2012_u6</version> <scope>system</scope> <systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/analyzer-2012_u6.jar</systemPath> </dependency>注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven仓库中引用依赖）。
type 一般在pom引用依赖时候出现，其他时候不用， optional 是否可选依赖。
依赖也可以是可选的，比如我们代码中没有任何cache依赖，但是hibernate可能要配置cache，所以该cache的依赖就是可选的。
maven的多项目管理也是非常强大的。一般来说，maven要求同一个工程的所有子项目都放置到同一个目录下，每一个子目录代表一个项目，比如
总项目/ pom.xml 总项目的 pom 配置文件
子项目1/pom.xml 子项目1的 pom 文件
子项目2/ pom.xml 子项目2的 pom 文件
按照这种格式存放，就是继承方式，所有具体子项目的pom.xml都会继承总项目pom的内容，取值为子项目pom内容优先。
要设置继承方式，首先要在总项目的pom中加入如下配置
<modules> <module>simple-weather</module> <module>simple-webapp</module> </modules>
其次在每个子项目中加入
<parent> <groupId>org.sonatype.mavenbook.ch06</groupId> <artifactId>simple-parent</artifactId> <version>1.0</version> </parent>
当然，继承不是唯一的配置文件共用方式，maven还支持引用方式。引用pom的方式更简单，在依赖中加入一个type为pom的依赖即可。
<dependency> <groupId>org.sonatype.mavenbook</groupId> <artifactId>persistence-deps</artifactId> <version>1.0</version> <type>pom</type> </dependency>
用户可以在maven中定义一些属性，然后在其他地方用${xxx}进行引用。比如：
value1
maven 提供了三个隐式的变量，用来访问系统环境变量、POM信息和 maven 的 settings：
env 暴露操作系统的环境变量，比如 env.PATH
project 暴露 POM 中的内容，用点号(.)的路径来引用POM元素的值，比如 ${project.artifactId}。另外，java的系统属性比如user.dir等，也暴露在这里。
settings 暴露 maven 的 settings 的信息，也可以用点号(.)来引用。
profile 是 maven 的一个重要特性，它可以让 maven 能够自动适应外部的环境变化。
比如同一个项目，在linux下编译linux的版本，在win下编译win的版本等。
一个项目可以设置多个 profile，也可以在同一时间设置多个 profile 被激活（active）的。
自动激活的 profile 的条件可以是各种各样的设定条件，组合放置在 activation 节点中，也可以通过命令行直接指定。
profile 包含的其他配置内容可以覆盖掉 pom 定义的相应值。
如果认为 profile 设置比较复杂，可以将所有的 profiles 内容移动到专门的 profiles.xml 文件中，不过记得和 pom.xml 放在一起。
maven的主执行程序为 mvn.bat，linux下为mvn.sh，这两个程序都很简单，它们的共同用途就是收集一些参数，然后用 java.exe来运行maven的Main函数。
maven 同样需要有配置文件，名字叫做 settings.xml，它放在两个地方，一个是 maven 安装目录的conf目录下，对所有使用该 maven 的用户都起作用。
我们称为主配置文件，另外一个放在 %USERPROFILE%/.m2/settings.xml 下，我们成为用户配置文件，只对当前用户有效，且可以覆盖主配置文件的参数内容。
还有就是项目级别的配置信息了，它存放在每一个 maven 管理的项目目录下，叫 pom.xml，主要用于配置项目相关的一些内容。
当然，如果有必要用户也可以在 pom 中写一些配置，覆盖住配置文件和用户配置文件的设置参数内容。
一般来说，settings文件配置的是比如repository库路径之类的全局信息，具体可以参考官方网站的文章。
在maven中一般都会用到安装库文件的功能，一则是我们常用的hibernate要使用jmx库，但是因为sun的license限制，所以无法将其直接包含在repository中。
所以我们使用mvn命令把jar安装到我们本地的repository中
mvn install:install-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
如果我们想把它安装到公司的repository中，需要使用命令
mvn deploy:deploy-file -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl= -DrepositoryId=release-repo
对于我们的工程输出，如果需要放置到公司的repository中的话，可以通过配置 pom 来实现
<distributionManagement> <repository> <id>mycompany-repository</id> <name>MyCompany Repository</name> <url>scp://repository.mycompany.com/repository/maven2</url> </repository> </distributionManagement>
1. 创建Maven的普通java项目： mvn archetype:create -DgroupId=packageName -DartifactId=projectName 2. 创建Maven的Web项目： mvn archetype:create -DgroupId=packageName -DartifactId=webappName -DarchetypeArtifactId=maven-archetype-webapp 3. 编译源代码： mvn compile 4. 编译测试代码：mvn test-compile 5. 运行测试：mvn test 6. 产生site：mvn site 7. 打包：mvn package 8. 在本地Repository中安装jar：mvn install 9. 清除产生的项目：mvn clean 10. 生成eclipse项目：mvn eclipse:eclipse 11. 生成idea项目：mvn idea:idea 12. 组合使用goal命令，如只打包不测试：mvn -Dtest package 13. 编译测试的内容：mvn test-compile 14. 只打jar包: mvn jar:jar 15. 只测试而不编译，也不测试编译：mvn test -skipping compile -skipping test-compile ( -skipping 的灵活运用，当然也可以用于其他组合命令) 16. 清除eclipse的一些系统设置:mvn eclipse:clean
위 내용은 Maven 개요 및 사용법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
