maven 工程的lib

maven 的安装

配置MAVEN_HOME

windows path 和 Linux的 .bash_profile

Maven的原则：约定优于配置。

它提出这一概念，为项目提供合理的默认行为，无需不必要的配置。提供了默认的目录：

src                  源代码和测试代码的根目录
|---main             应用代码的源目录
|------java          源代码
|------resources     项目的资源文件
|---test             测试代码的源目录
|------java          测试代码
|------resources     测试的资源文件
|---target           编译后的类文件、jar文件等

Setting文件解析

本地仓库

代理

镜像

插件管理

不同的环境可以使用不同的profile。

脚手架：自己百度去。以POM文件建立的脚手架，以GRADLE建立的脚手架。

POM文件解析

使用的POM文件的标准

公司的标识，或者组织的标识

脚手架这个节点标识，也是功能标识

版本号

打包的类型 jar, war，maven-plugin等

描述

… 变量定义

<mybatis.version>1.0.0-SANPSHOT</mybatis.version>

只能出现在父节点的POM文件之中。统一版本号。通过它元素来管理jar包的版本，让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号。

• compile。默认，编译。
• test 测试
• runtime 运行时，面向接口编程
• provided 编译
• system 本地一些jar。

依赖继承

父亲的pom文件：

<dependencyManagement>
	<dependency>
        <groupId>com.tal</groupId>
        <artifactId>parent</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
</dependencyManagement>

子节点的pom文件

<parent>
	... <!-- 引入父亲的pom文件 -->
</parent>

<dependencies>
    <dependency>
    	<groupId>com.tal</groupId>
        <artifactId>parent</artifactId>
    </dependency>
</dependencies>

依赖传递

横-父POM	compile	test	provided	runtime
compile	compile	–	-	runtime
test	test	-	-	test
provided	provided	-	provided	provided
runtime	runtime	-	-	runtime

依赖仲裁

• 最小路径原则
• 加载先后原则
• exclusions

<exclusions>
	<exclusion>
		<artifactId></artifactId>
		<groupId></groupId>
	</exclusion>
</exclusions>

生命周期

A Build Lifecycle is Made Up of Phases 一个生命周期是由多个阶段组成。

A Build Phase is Made Up of Plugin Goals 一个阶段由多个插件的goals组成。

1. clean Lifecycle

• pre-clean
• clean
• post-clean

2. default

• compile
• package
• install
• deploy

Default Lifecycle
validate	test-complie
initialize	process-test-classes
generate-sources	test
process-soureces	prepare-package
generate-resources	package
process-resources	pre-integration
compile	integration-test
process-classes	post-integration
generate-test-sources	verify
process-test-sources	install
generate-test-resources	deploy
process-test-resources

1. site Lifecycle

• pre-site
• site
• post-site
• site-deploy

了解了生命周期才会写plugins

<plugin>
    <groupId>com.taobao.pandora</groupId>
    <artifactId>pandora-boot-maven-plugin</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <configuration>
        <excludeSar>true</excludeSar>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

强制拉版本：mvn package -U

版本管理

1. 1.0.0-SNAPSHOT
2. 主版本号.次版本号.增量版本号 – <里程碑版本>

• 1.0.0-RELAESE

插件

1. 常用插件
   https://maven.apache.org/plugins/https://www.codehaus.org/plugins/

• findbugs 静态代码检查
• versions 统一升级版本
• source打包源代码
• assembly 打包zip，war
• tomcat7

2. 自定义插件

@Mojo(name = "myPlugins", defaultPhase=LifecyclePhase.PACKAGE)
public class MyPlugin extends AbstractMogo {
    
    @Parameters
    private String msg;
    
    @Parameters
    private List<String> options;
    
    @Parameter(property="args")
    private List<String> args;
    
    @Override
    public void execute() {
        System.out.println("我的插件  测试"+msg+opetions+args);
    }

}

插件的pom.xml文件

<project ...>
    <groupId>com.tal</groupId>
    <artifactId>test-myPlugin</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>maven-plugin</packaging>
    
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.apache.maven</groupId>
            <artifactId>maven-plugin-api</artifactId>
            <version>3.5.0</version>
        </dependency>
        <dependency>
            <groupId>org.apache.maven.plugin-tools</groupId>
            <artifactId>maven-plugin-annotations</artifactId>
            <version>3.5</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</project>

应用自定义插件的xml文件

<build>
    <plugins>
        <plugin>
			<groupId>com.tal</groupId>
            <artifactId>test-myPlugin</artifactId>
            <version>1.0.0-SNAPSHOT</version>
            <configuration>
            	<msg>This is msg!</msg>
                <options>
                	<option>one</option>
                    <option>two</option>
                    <option>three</option>
                </options>
            </configuration>
			<executions>
            	<execution>
                	<phase>package</phase>
                    <goals>
                    	<goal>myPlugins</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

看系统变量：mvn help:system

Profile

不同的场景使用不同的profile打包

<profiles>
	<profile>
    	<id>dev</id>
        <properties>
        	<profiles.active>dev</profiles.active>
            <activation>
            	<activeByDefault>true</activeByDefault>
            </activation>
        </properties>
    </profile>
    <profile>
        <id>dev</id>
        <properties>
        	<profiles.active>dev</profiles.active>
        </properties>
    </profile>
</profiles>

指定mvn执行的profile：mvn install -P dev

仓库

1. 下载
2. 发布

<distrutionManagement>
</distrutionManagement>

3. 下载jar配置

• 配置mirror
• profile

4. archetype模板化

• 步骤1： 运行命令： mvn archetype:create-from-project
• 步骤2: cd /target/generate-sources/archetype
• 步骤3： mvn install/ mvn deploy
• 步骤4：idea和eclipse创建maven工程的时候添加指定本地或者远程的archetype

依赖的Scope

scope定义了类包在项目的使用阶段。项目阶段包括： 编译，运行，测试和发布。

分类说明

compile

默认scope为compile，表示为当前依赖参与项目的编译、测试和运行阶段，属于强依赖。打包之时，会达到包里去。

test

该依赖仅仅参与测试相关的内容，包括测试用例的编译和执行，比如定性的Junit。

runtime

依赖仅参与运行周期中的使用。一般这种类库都是接口与实现相分离的类库，比如JDBC类库，在编译之时仅依赖相关的接口，在具体的运行之时，才需要具体的mysql、oracle等等数据的驱动程序。
此类的驱动都是为runtime的类库。

provided

该依赖在打包过程中，不需要打进去，这个由运行的环境来提供，比如tomcat或者基础类库等等，事实上，该依赖可以参与编译、测试和运行等周期，与compile等同。区别在于打包阶段进行了exclude操作。

system

使用上与provided相同，不同之处在于该依赖不从maven仓库中提取，而是从本地文件系统中提取，其会参照systemPath的属性进行提取依赖。

import

这个是maven2.0.9版本后出的属性，import只能在dependencyManagement的中使用，能解决maven单继承问题，import依赖关系实际上并不参与限制依赖关系的传递性。