Maven 生命周期和构建原理

谁借莪１个温暖的怀抱￠ 2022-02-21 15:45 245阅读 0赞

maven是一个非常经典的和通用的项目管理工具，虽然现在热炒gradle将作为下一代 项目管理工具来取代maven,但是 由于maven强大和健全的功能，maven还有很强的生命力。

本文将介绍maven对于项目生命周期的设计以及原理。

> **读完本文，你将了解到：**
> 
> **一、maven对项目生命周期的抽象--三大项目生命周期**  
> 
> 
> **二、maven对项目默认生命周期的抽象**  
> 
> 
> **三、maven指令与生命周期阶段的关系**  
> 
> 
> **四、maven生命周期各个阶段的行为与maven默认行为**  
> 
> 
> **五、maven项目的目录结构**  
> 
> 
> **六、maven为生命周期阶段绑定特定行为动作的机制即插件原理**

##  ##

一、 maven对项目生命周期的抽象--三大项目生命周期

![20160114172754981][]

maven从项目的三个不同的角度，定义了单套生命周期，三套生命周期是相互独立的，它们之间不会相互影响。

**默认构建生命周期（Default Lifeclyle）:** 该生命周期表示这项目的构建过程，定义了一个项目的构建要经过的不同的阶段。

**清理生命周期(Clean Lifecycle): **该生命周期负责清理项目中的多余信息，保持项目资源和代码的整洁性。一般拿来清空directory(即一般的target)目录下的文件。

**站点管理生命周期(Site Lifecycle) :**向我们创建一个项目时，我们有时候需要提供一个站点，来介绍这个项目的信息，如项目介绍，项目进度状态、项目组成成员，版本控制信息，项目javadoc索引信息等等。站点管理生命周期定义了站点管理过程的各个阶段。

本文只介绍maven项目默认的生命周期，其他两个生命周期将另起博文介绍。

##  ##

二、 maven对项目默认生命周期的抽象

> ![20160114103206331][]

> 
> 
> 
> **如何查看maven对默认生命周期的定义？**
> 
>     maven将其架构和结构的组织放置到了components.xml 配置文件中，该配置文件的路径是:
> 
>            ***apache-maven-$\{version\}\\lib******\\maven-core-$\{version\}.jar\\META-INFO\\plexus\\conponents.xml***文件中。其中，我们可以看到关于default生命周期XML节点配置信息：
> 
> > <component> 
> > <role>org.apache.maven.lifecycle.Lifecycle </role> 
> > <implementation>org.apache.maven.lifecycle.Lifecycle </implementation> 
> > <role-hint>default </role-hint> 
> > <configuration> 
> > <id>default </id> 
> > 
> > <phases> 
> > <phase>validate </phase> 
> > <phase>initialize </phase> 
> > <phase>generate-sources </phase> 
> > <phase>process-sources </phase> 
> > <phase>generate-resources </phase> 
> > <phase>process-resources </phase> 
> > <phase>compile </phase> 
> > <phase>process-classes </phase> 
> > <phase>generate-test-sources </phase> 
> > <phase>process-test-sources </phase> 
> > <phase>generate-test-resources </phase> 
> > <phase>process-test-resources </phase> 
> > <phase>test-compile </phase> 
> > <phase>process-test-classes </phase> 
> > <phase>test </phase> 
> > <phase>prepare-package </phase> 
> > <phase>package </phase> 
> > <phase>pre-integration-test </phase> 
> > <phase>integration-test </phase> 
> > <phase>post-integration-test </phase> 
> > <phase>verify </phase> 
> > <phase>install </phase> 
> > <phase>deploy </phase> 
> > </phases> 
> > 
> > </configuration> 
> > </component>
> 
> 
> 
>

maven根据一个项目的生命周期的每个阶段，将一个项目的生命周期抽象成了如上图所示的23个阶段。而每一个阶段应该干什么事情由用户决定。换句话说，maven为每一个阶段设计了接口，你可以为每一阶段自己定义一个接口，进而实现对应阶段应该有的行为。关于如何为某个生命周期阶段绑定自定义的行为，我将在后面的章节介绍。

##  ##

三、 maven指令与生命周期阶段的关系

![20160114155000416][]

##  ##

四、maven生命周期各个阶段的行为与maven默认行为

> 使用过maven的读者会经常使用这些maven指令：  
> 
> 
>     mvn compile //让当前项目经历生命周期中的1-->7 阶段 ：完成编译主源代码编译 
>         mvn package //让当前项目经历生命周期中的1-->17阶段 ：完成打包 
>         mvn install //让当前项目经历生命周期中的1-->22阶段 ：完成包安装到本地仓库 
>         mvn deploy //让当前生命经历生命周期中的1-->23阶段 ：完成包部署到中心库中
> 
>   
> 在经历这些生命周期的阶段中，每个阶段会理论上会有相应的处理操作。但是，在实际的项目开发过程中， 并不是所有的生命周期阶段都是必须的。  
> 然而，在实际的开发过程中，往往我们的项目的一些生命周期的阶段不需要相应的行为，我们只需要关心其中某些重要的生命周期阶段而已。下面，请看一下日常开发中，我们需要关注的生命周期阶段，即广大开发人员对项目周期阶段处理的约定：  
> 1).应该将resource资源文件准备好，放到指定的target目录下----process-resources 阶段；  
> 2).将java源文件编译成.class文件，然后将class 文件放置到对应的target目录下----compile阶段；  
> 3).将test类型的resource移动到指定的 target目录下------process-test-resource阶段；  
> 4).将test类型的java 源文件编译成class文件，然后放置到指定的target目录下------test-compile阶段；  
> 5).运行test测试用例-------test阶段；  
> 6).将compile阶段编译的class文件和resource资源打包成jar包或war包--------package阶段；  
> 7).将生成的包安装到本地仓库中------install阶段  
> 8).将生成的包部署到远程仓库中-----deploy阶段

由上面的约定可以看出，在大多数情况下，大家关心的项目生命周期阶段仅仅是上面的8个而已。跟上面maven对生命周期阶段23个的抽象相比，这就少的很多了。

基于类似的约定，maven默认地为一些不同类型的maven项目生命周期的阶段实现了默认的行为。

maven 在设计上将***生命周期阶段的抽象***和***对应阶段应该执行的行为实现***分离开，maven这些实现放到了插件中，这些插件本质上是实现了maven留在各个生命周期阶段的接口。关于插件的问题，我将另外写一篇博文介绍。

> 如下图所示，maven针对不同打包类型的maven项目的生命周期阶段绑定了对应的默认行为：![20160110145341776][]  
>

> 如上图所示，对于不同的打包格式的项目而言，maven为特定类型的包格式项目在不同的生命周期阶段的默认行为。
> 
> 而对于我们经常使用的jar和war包格式的项目而言，maven总共为其规定了以下几个生命周期阶段的默认行为：

> ![20160110150247814][]  
>

##  ##

五、 maven项目的目录结构

> well,每个项目工程，都有非常繁琐的目录结构，每个目录都有不同的作用。请记住这一点，目录的划分是根据需要来的，每个目录有其特定的功能。目录本质上就是一个文件或文件夹路径而已。那么，我们换一个思路考虑：一个项目的文件结构需要组织什么信息呢？让我们来看一下功能的划分：

> ![20160114133042077][]  
>

> 如上图所示，你会看到maven项目里不同功能类型的目录定义以及maven默认的目录的路径。

> ***如何修改默认的目录配置***
> 
> 在maven项目工程对应project的 pom.xml中，在<project>--><build>节点下，你可以指定自己的目录路径信息：
> 
> <build> 
>  
> <sourceDirectory>E:\intellis\maven-principle\phase-echo\src\main\java </sourceDirectory> 
> <scriptSourceDirectory>E:\intellis\maven-principle\phase-echo\src\main\scripts </scriptSourceDirectory> 
> <testSourceDirectory>E:\intellis\maven-principle\phase-echo\src\test\java </testSourceDirectory> 
> <outputDirectory>E:\intellis\maven-principle\phase-echo\target\classes </outputDirectory> 
> <testOutputDirectory>E:\intellis\maven-principle\phase-echo\target\test-classes </testOutputDirectory> 
> 
>  
> <resources> 
> <resource> 
> <directory>E:\intellis\maven-principle\phase-echo\src\main\resources </directory> 
> </resource> 
> </resources> 
> 
>  
> <testResources> 
> <testResource> 
> <directory>E:\intellis\maven-principle\phase-echo\src\test\resources </directory> 
> </testResource> 
> </testResources> 
> 
> <directory>E:\intellis\maven-principle\phase-echo\target </directory> 
> 
> </build>
> 
> 
>

> **请注意：对于maven管理项目工程的生命周期的操作上， 都发生在上述的几种目录中。换句话说，实质上，maven的项目管理的整个过程，就是围绕着对上述几种文件目录中内容的操作。**

> ![20160114165224183][]  
>

##  ##

六、maven为生命周期阶段绑定特定行为动作的机制（即插件原理）

为maven生命周期的某些阶段绑定特定行为或动作，简单点就是调用一段代码而已，maven将需要执行的逻辑抽象成了一个接口，接口为 Mojo。Mojo是 Maven Old plain Java Object的简写，表示的意思是Mojo是maven的一个简单的对象。如下图所示：

![20160114190935734][]

maven通过为某一个项目的生命周期阶段绑定若干个Mojo,然后依次执行Mojo.execute()方法，从而实现特定生命周期应该执行的动作。

举例：比如，对于生命周期阶段process-resources，maven默认地为其绑定了一个Mojo:  org.apache.maven.plugin.resources.ResourcesMojo。

当需要经历process-resources阶段时，maven将会创建一个ResourcesMojo 实例instance，然后调用instance.execute()方法。

> @Mojo( name = "resources", defaultPhase = LifecyclePhase.PROCESS_RESOURCES, threadSafe = true ) 
> public class ResourcesMojo 
> extends AbstractMojo 
> implements Contextualizable 
> { 
> /** 
> 下面若干个attribute ，maven 读取pom.xml内的配置信息，这里的attribute对应着pom.xml里的配置，如果在这里声明了，maven在创建Mojo 实例 
> instance的时候，会将这些值注入到instance内，供Mojo instance使用 
> */ 
>   /** 
> * The character encoding scheme to be applied when filtering resources. 
> */ 
> @Parameter( property = "encoding", defaultValue = "${project.build.sourceEncoding}" ) 
> protected String encoding; 
> 
> /** 
> * The output directory into which to copy the resources. 
> */ 
> @Parameter( defaultValue = "${project.build.outputDirectory}", required = true ) 
> private File outputDirectory; 
> 
> /** 
> * The list of resources we want to transfer. 
> */ 
> @Parameter( defaultValue = "${project.resources}", required = true, readonly = true ) 
> private List<Resource> resources; 
> 
> /** 
> * 
> */ 
> @Parameter( defaultValue = "${project}", required = true, readonly = true ) 
> protected MavenProject project; 
> 
> /** 
> * The list of additional filter properties files to be used along with System and project 
> * properties, which would be used for the filtering. 
> * 
> * See also: { @link ResourcesMojo#filters}. 
> * 
> * @since 2.4 
> */ 
> @Parameter( defaultValue = "${project.build.filters}", readonly = true ) 
> protected List<String> buildFilters; 
> 
> /** 
> * The list of extra filter properties files to be used along with System properties, 
> * project properties, and filter properties files specified in the POM build/filters section, 
> * which should be used for the filtering during the current mojo execution. 
> * 
> * Normally, these will be configured from a plugin's execution section, to provide a different 
> * set of filters for a particular execution. For instance, starting in Maven 2.2.0, you have the 
> * option of configuring executions with the id's <code>default-resources</code> and 
> * <code>default-testResources</code> to supply different configurations for the two 
> * different types of resources. By supplying <code>extraFilters</code> configurations, you 
> * can separate which filters are used for which type of resource. 
> */ 
> @Parameter 
> protected List<String> filters; 
> 
> /** 
> * If false, don't use the filters specified in the build/filters section of the POM when 
> * processing resources in this mojo execution. 
> * 
> * See also: { @link ResourcesMojo#buildFilters} and { @link ResourcesMojo#filters} 
> * 
> * @since 2.4 
> */ 
> @Parameter( defaultValue = "true" ) 
> protected boolean useBuildFilters; 
> 
> /** 
> * 
> */ 
> @Component( role = MavenResourcesFiltering.class, hint = "default" ) 
> protected MavenResourcesFiltering mavenResourcesFiltering; 
> 
> /** 
> * 
> */ 
> @Parameter( defaultValue = "${session}", required = true, readonly = true ) 
> protected MavenSession session; 
> 
> /** 
> * Expression preceded with the String won't be interpolated 
> * \${foo} will be replaced with ${foo} 
> * 
> * @since 2.3 
> */ 
> @Parameter( property = "maven.resources.escapeString" ) 
> protected String escapeString; 
> 
> /** 
> * Overwrite existing files even if the destination files are newer. 
> * 
> * @since 2.3 
> */ 
> @Parameter( property = "maven.resources.overwrite", defaultValue = "false" ) 
> private boolean overwrite; 
> 
> /** 
> * Copy any empty directories included in the Resources. 
> * 
> * @since 2.3 
> */ 
> @Parameter( property = "maven.resources.includeEmptyDirs", defaultValue = "false" ) 
> protected boolean includeEmptyDirs; 
> 
> /** 
> * Additional file extensions to not apply filtering (already defined are : jpg, jpeg, gif, bmp, png) 
> * 
> * @since 2.3 
> */ 
> @Parameter 
> protected List<String> nonFilteredFileExtensions; 
> 
> /** 
> * Whether to escape backslashes and colons in windows-style paths. 
> * 
> * @since 2.4 
> */ 
> @Parameter( property = "maven.resources.escapeWindowsPaths", defaultValue = "true" ) 
> protected boolean escapeWindowsPaths; 
> 
> /** 
> * 
> * Set of delimiters for expressions to filter within the resources. These delimiters are specified in the 
> * form 'beginToken*endToken'. If no '*' is given, the delimiter is assumed to be the same for start and end. 
> * 
> * So, the default filtering delimiters might be specified as: 
> * 
> * <pre> 
> * <delimiters> 
> * <delimiter>${*}</delimiter> 
> * <delimiter>@</delimiter> 
> * </delimiters> 
> * </pre> 
> * 
> * Since the '@' delimiter is the same on both ends, we don't need to specify '@*@' (though we can). 
> * 
> * 
> * @since 2.4 
> */ 
> @Parameter 
> protected List<String> delimiters; 
> 
> /** 
> * @since 2.4 
> */ 
> @Parameter( defaultValue = "true" ) 
> protected boolean useDefaultDelimiters; 
> 
> /** 
> * 
> * List of plexus components hint which implements { @link MavenResourcesFiltering#filterResources(MavenResourcesExecution)}. 
> * They will be executed after the resources copying/filtering. 
> * 
> * 
> * @since 2.4 
> */ 
> @Parameter 
> private List<String> mavenFilteringHints; 
> 
> /** 
> * @since 2.4 
> */ 
> private PlexusContainer plexusContainer; 
> 
> /** 
> * @since 2.4 
> */ 
> private List<MavenResourcesFiltering> mavenFilteringComponents = new ArrayList<MavenResourcesFiltering>(); 
> 
> /** 
> * stop searching endToken at the end of line 
> * 
> * @since 2.5 
> */ 
> @Parameter( property = "maven.resources.supportMultiLineFiltering", defaultValue = "false" ) 
> private boolean supportMultiLineFiltering; 
> 
> public void contextualize( Context context ) 
> throws ContextException 
> { 
> plexusContainer = (PlexusContainer) context.get( PlexusConstants.PLEXUS_KEY ); 
> } 
> 
> public void execute() 
> throws MojoExecutionException 
> { 
> try 
> { 
> 
> if ( StringUtils.isEmpty( encoding ) && isFilteringEnabled( getResources() ) ) 
> { 
> getLog().warn( "File encoding has not been set, using platform encoding " + ReaderFactory.FILE_ENCODING 
> + ", i.e. build is platform dependent!" ); 
> } 
> //获取资源文件过滤器配置 
> List filters = getCombinedFiltersList(); 
> //根据现有配置信息创建Resources处理器对象实例 
> MavenResourcesExecution mavenResourcesExecution = 
> new MavenResourcesExecution( getResources(), getOutputDirectory(), project, encoding, filters, 
> Collections.<String>emptyList(), session ); 
> //windows路径处理 
> mavenResourcesExecution.setEscapeWindowsPaths( escapeWindowsPaths ); 
> 
> // never include project build filters in this call, since we've already accounted for the POM build filters 
> // above, in getCombinedFiltersList(). 
> mavenResourcesExecution.setInjectProjectBuildFilters( false ); 
> 
> mavenResourcesExecution.setEscapeString( escapeString ); 
> mavenResourcesExecution.setOverwrite( overwrite ); 
> mavenResourcesExecution.setIncludeEmptyDirs( includeEmptyDirs ); 
> mavenResourcesExecution.setSupportMultiLineFiltering( supportMultiLineFiltering ); 
> 
> // if these are NOT set, just use the defaults, which are '${*}' and '@'. 
> if ( delimiters != null && !delimiters.isEmpty() ) 
> { 
> LinkedHashSet<String> delims = new LinkedHashSet<String>(); 
> if ( useDefaultDelimiters ) 
> { 
> delims.addAll( mavenResourcesExecution.getDelimiters() ); 
> } 
> 
> for ( String delim : delimiters ) 
> { 
> if ( delim == null ) 
> { 
> // FIXME: ${filter:*} could also trigger this condition. Need a better long-term solution. 
> delims.add( "${*}" ); 
> } 
> else 
> { 
> delims.add( delim ); 
> } 
> } 
> 
> mavenResourcesExecution.setDelimiters( delims ); 
> } 
> 
> if ( nonFilteredFileExtensions != null ) 
> { 
> mavenResourcesExecution.setNonFilteredFileExtensions( nonFilteredFileExtensions ); 
> } 
> mavenResourcesFiltering.filterResources( mavenResourcesExecution ); 
> //执行Resource文件拷贝 
> executeUserFilterComponents( mavenResourcesExecution ); 
> } 
> catch ( MavenFilteringException e ) 
> { 
> throw new MojoExecutionException( e.getMessage(), e ); 
> } 
> } 
> 
> /** 
> * @since 2.5 
> */ 
> protected void executeUserFilterComponents( MavenResourcesExecution mavenResourcesExecution ) 
> throws MojoExecutionException, MavenFilteringException 
> { 
> 
> if ( mavenFilteringHints != null ) 
> { 
> for ( Iterator ite = mavenFilteringHints.iterator(); ite.hasNext(); ) 
> { 
> String hint = (String) ite.next(); 
> try 
> { 
> mavenFilteringComponents.add( 
> (MavenResourcesFiltering) plexusContainer.lookup( MavenResourcesFiltering.class.getName(), 
> hint ) ); 
> } 
> catch ( ComponentLookupException e ) 
> { 
> throw new MojoExecutionException( e.getMessage(), e ); 
> } 
> } 
> } 
> else 
> { 
> getLog().debug( "no use filter components" ); 
> } 
> 
> if ( mavenFilteringComponents != null && !mavenFilteringComponents.isEmpty() ) 
> { 
> getLog().debug( "execute user filters" ); 
> for ( MavenResourcesFiltering filter : mavenFilteringComponents ) 
> { 
> filter.filterResources( mavenResourcesExecution ); 
> } 
> } 
> } 
> 
> protected List<String> getCombinedFiltersList() 
> { 
> if ( filters == null || filters.isEmpty() ) 
> { 
> return useBuildFilters ? buildFilters : null; 
> } 
> else 
> { 
> List<String> result = new ArrayList<String>(); 
> 
> if ( useBuildFilters && buildFilters != null && !buildFilters.isEmpty() ) 
> { 
> result.addAll( buildFilters ); 
> } 
> 
> result.addAll( filters ); 
> 
> return result; 
> } 
> } 
> 
> /** 
> * Determines whether filtering has been enabled for any resource. 
> * 
> * @param resources The set of resources to check for filtering, may be <code>null</code>. 
> * @return <code>true</code> if at least one resource uses filtering, <code>false</code> otherwise. 
> */ 
> private boolean isFilteringEnabled( Collection<Resource> resources ) 
> { 
> if ( resources != null ) 
> { 
> for ( Resource resource : resources ) 
> { 
> if ( resource.isFiltering() ) 
> { 
> return true; 
> } 
> } 
> } 
> return false; 
> } 
> }
> 
> 
> 
> 
> 上面只是介绍了Maven生命周期阶段绑定执行代码的基本模式，由于maven的生命周期众多，并且每个生命周期内有可能绑定多个Mojo，如果使用上述的模式简单关联的话，会显得结构组织很乱。
> 
> maven会根据Mojo功能的划分，将具有相似功能的Mojo放到一个插件中。并且某一个特定的Mojo能实现的功能称为 goal,即目标，表明该Mojo能实现什么目标。
> 
> ![20160115102408068][]
> 
> 
> 
> 
> 例如，我们项目生命周期有两个阶段：compile 和 test-compile,这两阶段都是需要将java源代码编译成class文件中，相对应地，compile和test-compiler分别被绑定到了org.apache.maven.plugin.compiler.CompilerMojo 和org.apache.maven.plugin.compiler.TestCompilerMojo上：
> 
> ![20160115134039558][]
> 
> 如何查看maven各个生命周期阶段和插件的绑定情况
> 
> maven默认实现上，会为各个常用的生命周期根据约定绑定特定的插件目标。maven将这些配置放置到了：
> 
> ***apache-maven-$\{version\}\\lib******\\maven-core-$\{version\}.jar\\META-INFO\\plexus\\default-binds.xml文件中，针对不同打包类型的项目，其默认绑定情况也会不一样，我们先看一下常用的jar包类型和war包类型的项目默认绑定情况：***
> 
> 
> 
> 
>  
> <component> 
> <role>org.apache.maven.lifecycle.mapping.LifecycleMapping </role> 
> <role-hint>jar </role-hint> 
> <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping </implementation> 
> <configuration> 
> <lifecycles> 
> <lifecycle> 
> <id>default </id> 
>  
> <phases> 
>  
> <process-resources> 
> org.apache.maven.plugins:maven-resources-plugin:2.6:resources 
> </process-resources> 
> <compile> 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile 
> </compile> 
> <process-test-resources> 
> org.apache.maven.plugins:maven-resources-plugin:2.6:testResources 
> </process-test-resources> 
> <test-compile> 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile 
> </test-compile> 
> <test> 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test 
> </test> 
> <package> 
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar 
> </package> 
> <install> 
> org.apache.maven.plugins:maven-install-plugin:2.4:install 
> </install> 
> <deploy> 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy 
> </deploy> 
> </phases> 
>  
> </lifecycle> 
> </lifecycles> 
> </configuration> 
> </component> 
> 
>  
> <component> 
> <role>org.apache.maven.lifecycle.mapping.LifecycleMapping </role> 
> <role-hint>war </role-hint> 
> <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping </implementation> 
> <configuration> 
> <lifecycles> 
> <lifecycle> 
> <id>default </id> 
>  
> <phases> 
> <process-resources> 
> org.apache.maven.plugins:maven-resources-plugin:2.6:resources 
> </process-resources> 
> <compile> 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile 
> </compile> 
> <process-test-resources> 
> org.apache.maven.plugins:maven-resources-plugin:2.6:testResources 
> </process-test-resources> 
> <test-compile> 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile 
> </test-compile> 
> <test> 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test 
> </test> 
> <package> 
> org.apache.maven.plugins:maven-war-plugin:2.2:war 
> </package> 
> <install> 
> org.apache.maven.plugins:maven-install-plugin:2.4:install 
> </install> 
> <deploy> 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy 
> </deploy> 
> </phases> 
>  
> </lifecycle> 
> </lifecycles> 
> </configuration> 
> </component>
> 
> 
> 如果你想查看当前maven有多少插件，每个插件都干了什么，你可以访问 maven plugin主页了解 ： [ http://maven.apache.org/plugins/index.html][http_maven.apache.org_plugins_index.html] 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 写在最后
> 
> 本文旨在向读者介绍maven默认生命周期的工作机制，以及maven在项目构建过程中的基本原理和机制。
> 
> 本文介绍的比较宽泛，还没有深入到maven插件底层，随后一篇博文将会详细介绍插件，解析插件的工作原理，分析当前maven默认定义的插件，并最终自己定义插件完成特定功能，敬请关注！
> 
> 由于本人技术有限，如果本人有任何错误和纰漏，请读者慷慨指出，共同学习，共同进步！ 
> 
> 
> 
> 
> 
> **2016.1.15** 
> 
> 
> 
>

[20160114172754981]: /images/20220221/8d94de8be4a142829a0f315d381562fa.png
[20160114103206331]: /images/20220221/72e543083a6141bf8a6f5c8f09abb232.png
[20160114155000416]: /images/20220221/e5cabc469e0f4efc86802478c44d0af1.png
[20160110145341776]: /images/20220221/c8cecbc3b94748b1ab4b825f311e867c.png
[20160110150247814]: /images/20220221/1d3d84142d19409db5dc55da14c7ab63.png
[20160114133042077]: /images/20220221/59ffc5b1538642b2817a82f7a401de2e.png
[20160114165224183]: /images/20220221/f4b993c469c54f77b9538485d120339a.png
[20160114190935734]: /images/20220221/4c7de86601ad4df999aded58dbe3d8e4.png
[20160115102408068]: /images/20220221/055044d47a514820974656342718d56b.png
[20160115134039558]: /images/20220221/74c05dc3441c42b786b37c92d7673ddc.png
[http_maven.apache.org_plugins_index.html]: http://maven.apache.org/plugins/index.html