pom文件及maven、docker笔记

1. pom内容

pom文件一打开，有这么几个大块的分组：

（1）dependency

dependency内部通过groupId,artufactId以及version确定唯一的依赖
groupId: 组织的唯一标识。
artifactId: 项目的唯一标识。
version：项目的版本。

（2）properties

应该是自定义的属性值，为了在pom的其他地方引用这些properties
<properties>
    <mysql.version>5.1.1</mysql.version>
</properties>

（3）编译插件plugin

2. spring-boot-maven-plugin

（1） 如果你的POM是继承spring-boot-starter-parent的话，只需要下面的指定就行。

<properties>
    <!-- The main class to start by executing java -jar -->
    <start-class>com.mycorp.starter.HelloWorldApplication</start-class>
</properties>

（2）如果你的POM不是继承spring-boot-starter-parent的话，需要下面的指定。

    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <version>1.3.5.RELEASE</version>
      <configuration>
        <mainClass>${start-class}</mainClass>
        <layout>ZIP</layout>
      </configuration>
      <executions>
        <execution>
          <goals>
            <goal>repackage</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

---

上面这两种情况的原理，是由于你引入了<parent>，然后springboot的parent在build的子标签里面有pluginManagement，已经把springboot-maven-plugin这个插件的很多都写出来了，唯一就是引用了一个${start-class}，所以你补上就行。
如果没继承这个parent，那么写出来的跟抄这个parent下面是一样的。
（这里又涉及到另一个只是，只要是pom里面的Maganement，无论是dependencyManagement还是pluginManagement，都是在父工程里面用的，在父工程里面用了之后，子工程直接继承，所以你多半不会自己去主动定义。）

                <plugin>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-maven-plugin</artifactId>
                    <executions>
                        <execution>
                            <goals>
                                <goal>repackage</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                        <mainClass>${start-class}</mainClass>
                    </configuration>
                </plugin>

• configuration：该插件所需要的特殊配置，在父子项目之间可以覆盖或合并
• executions：plugin 可以有多个目标，每一个目标都可以有一个分开的配置，甚至可以绑定一个 plugin 的目标到一个不同的阶段。executions 配置一个 plugin 的目标的 execution。一个 execution 有如下设置：
  • id，唯一标识
  • goals，要执行的插件的 goal（可以有多个），如 <goal>repackage</goal>
  • phase，目标执行的阶段，具体值看Maven的生命周期列表
  • inherited，该 execution 是否可被子项目继承
  • configuration，该 execution 的其他配置参数
    （execution里面的这几个子项，应该只有上三个有用。以及这些都是事先被定义好的流程，你写的这些都是在给别人的框架传配置。）

execution是一个执行任务，configuration是这个任务能用到的参数，有一些configuration是plugin用的，有一些是execution用的，反正都是框架定义好的参数，你只要传递就行了。
execution里面有用的只有一个goal，goal应该只会需要repackage模式，经过了这个repackage之后，打出来的包才有两个，一个是.original，一个是.jar，maven第一次打出来的包再次打包的时候变成了.original，然后第二次打包结果变成.jar。从体积上来计算，.original是几百k，源代码也是几百k，而.jar是几十兆，应该是一个胖包一个瘦包，再次打包的过程把所有的依赖都打进去了。

3. docker-maven-plugin

思路：首先知道根据dockerfile是怎么打包的，
这里开始解析dockerfile里面的每一句，
然后把dockerfile变成pom里面的<>。

（1） dockerfile内容

#父镜像
FROM java:8
#拷贝jar包
ADD scm.jar app.jar
#暴露接口
EXPOSE 8080
#启动容器的时候运行jar包
ENTRYPOINT [ "java", "-jar", "/app.jar" ]

如果真写起来dockerfile的话，上面应该就够用了。
dockerfile里面的四句话，父镜像，添加jar，运行jar，-p暴露端口。
（要调研的应该也就是Add和Entrypoint这两个有什么区别，或者不调研了）
Copy和Add用法好像一样的，都是Copy/Add + 要复制的jar + 别名

（2）使用dockefile结合插件

<build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        <!--使用docker-maven-plugin插件-->
        <plugin>
            <groupId>com.spotify</groupId>
            <artifactId>docker-maven-plugin</artifactId>
            <version>1.0.0</version>

            <!--将插件绑定在某个phase执行，下面的这个execution发挥的作用就是把这个docker打包镜像的过程绑定到了maven-plugin上面去-->
            <executions>
                <execution>
                    <id>build-image</id>
                    <!--用户只需执行mvn package ，就会自动执行mvn docker:build-->
                    <phase>package</phase>
                    <goals>
                        <goal>build</goal>
                    </goals>
                </execution>
            </executions>

            <configuration>
                <!--指定生成的镜像名-->
                <imageName>${docker.image.prefix}/${project.artifactId}</imageName>
                <!--指定标签-->
                <imageTags>
                    <imageTag>latest</imageTag>
                </imageTags>
                <!-- 指定 Dockerfile 路径-->
                <dockerDirectory>${project.basedir}</dockerDirectory>
                <!--指定远程 docker api地址-->
                <dockerHost>http://10.112.158.59:2375</dockerHost>

                <!-- 这里是复制 jar 包到 docker 容器指定目录配置，相当于dockerfile里面的那句Add -->
                <resources>
                    <resource>
                        <targetPath>/</targetPath>
                        <!--需要复制的jar 包所在的路径  此处配置的 即对应 target 目录，这个表达式你背下来就行了不用变-->
                        <directory>${project.build.directory}</directory>
                        <!-- 需要复制的 jar包 ，这里对应的是 Dockerfile中添加的文件名，也是背下来就行了　-->
                        <include>${project.build.finalName}.jar</include>
                    </resource>
                </resources>
            </configuration>
        </plugin>
    </plugins>
</build>

（3） 完全使用pom文件

这个是结合上面的那一份代码，改动了其中的dockerfile的那一句，变成了另外三句（其中的copy语句是下面的resource）。
以及下面这份文档应该是可以直接复制的，除了中间有服务器地址和端口号两个之外感觉别的都不用变。

<build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>


            <!-- 跳过单元测试 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <skipTests>true</skipTests>
                </configuration>
            </plugin>

            <!--使用docker-maven-plugin插件-->
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>1.0.0</version>
                <!--将插件绑定在某个phase执行-->
                <executions>
                    <execution>
                        <id>build-image</id>
                        <!--用户只需执行mvn package ，就会自动执行mvn docker:build-->
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>

                <configuration>
<!--                    这里是生成dockerfile的，也就是不需要自己写dockerfile了，直接在这个pom里面定义！！！！流弊！！！
                           dockerfile里面的每一行在这里面都有一个标签名<>对应着-->
                    <!--指定生成的镜像名，这里注意docker生成文件的前缀，在上面要有一个properties来定义这个前缀-->
                    <imageName>${docker.image.prefix}/${project.artifactId}</imageName>
                    <!--指定标签-->
                    <imageTags>
                        <imageTag>latest</imageTag>
                    </imageTags>
                    <!--指定远程 docker api地址（！！！这里要变化）-->
                    <dockerHost>http://10.112.158.59:2375</dockerHost>

                    <!-- 指定 Dockerfile 路径-->
<!--                    <dockerDirectory>${project.basedir}</dockerDirectory>-->

                    <!-- 从这里开始是重点了-->
                    <baseImage>java:8</baseImage>
                    <entryPoint>["java", "-jar", "/${project.build.finalName}.jar"]</entryPoint>
                    <exposes>
                        <!--（！！！）这个暴露接口也要变化 -->
                        <expose>7050</expose>
                    </exposes>

                    <!-- 这里是复制 jar 包到 docker 容器指定目录配置 -->
                    <resources>
                        <resource>
                            <targetPath>/</targetPath>
                            <!--jar 包所在的路径  此处配置的 即对应 target 目录-->
                            <directory>${project.build.directory}</directory>
                            <!-- 需要包含的 jar包 ，这里对应的是 Dockerfile中添加的文件名　-->
                            <include>${project.build.finalName}.jar</include>
                        </resource>
                    </resources>
                </configuration>

            </plugin>
        </plugins>
    </build>

（4） 生成镜像之后是要用下面的视图来启动容器的

至于这个视图启动容器看着就简单，就不写了。

4. maven

（1） maven项目结构

构建打包技术，发展历史是make -> ant -> maven -> gradle

maven工程中各目录结构含义

也就是说现在的工程就是一个maven工程，所以现在的src、pom、resource什么的全都是由这个maven工程来决定的，这是maven的约定，让maven知道什么的东西放在哪里，然后可以自动化构建。、

（2）maven依赖

首先是依赖的排除，一定是一个很大的依赖，里面一堆二级子依赖，然后这里面的一堆想排除哪个哪个，在这个大依赖的标签下面写排除。

<dependency>
     <exclusion>

然后是依赖冲突，如果对于一个依赖的好几个版本都声明了，两个原则。首先是路径最短的优先，你直接引用是要比在别的大包里面带进来要优先的；如果路径一样，先声明的优先，如果都是大包带进来的，那么排在上面的优先。

最后是统一管理依赖的版本。原理大概就是在pom里面的<properties>里面声明各种自定义属性，然后在下面引用dependency的时候，在version里面用${}来引用上面定义的属性。应该是应用于一个体系的框架内的所有引用，比如spring框架的很多东西，把这些所有与spring相关的引用版本保持一致。

（3） maven生命周期

• clean应该是删除target吧
• compile是把.java变成.class文件
• test是执行test文件夹里面的测试程序
• package是在target文件夹里面生成很多包括jar包在内的很多东西
• install是把jar包拷贝到本地的maven仓库，然后本机上的其他工程就能引用这个工程的依赖。
• deploy是把jar包拷贝到servlet里面运行，这个目前没啥用了，达到的效果是在本机上把程序跑起来，有一种愚蠢的启动办法，是把项目打包成jar包，然后把jar包拷贝到Tomcat里面去运行，deploy完成了这个功能，当然现在都能用Idea直接run就没必要了。
• site也是只能在服务器上执行的，用Shell命令mvn site xxxx什么的，所以没啥卵用。

所以总结，最终在idea上的mvn插件里面有用的仍然只有一个clean和package。
以及maven的常用命令，mvn开头的那几个Linux命令，完完全全就对应了上面的这几个指令，clean、test、package什么的。

（4） maven的坐标

跟上面的maven依赖联系起来。

• groupId：组织标识，一般为：公司网址的反写+项目名
• artifactId：项目名称，一般为：项目名-模块名
• version：版本号

所有的maven项目都要有上面的三个坐标，三个加起来就在仓库里面唯一确定了这个依赖。dependency引用的时候也是用这三个加起来就能指定到底引用哪一个项目，所以dependency下面有用的也是这三个。

（5）继承 <parent>

这个是为了在一个父工程里面统一管理依赖版本的。
用处就是在父工程里面定义一个<dependencyManagement>，在这里面定义各种<dependency>，写上版本号。
再之后在子工程里面继承这个parent，子工程里面再引用各种dependency的时候就可以不写版号了。
（这个parent不能给子工程引入依赖，只是对依赖版本version的统一管理）

（6）聚合 <module>

module这个，如果聚合起来了的话，从parent入口那里可以直接把所有的项目一键打包并且复制到本机的Tomcat，所有工程的一键部署吧（学了之后感觉没卵用）

（7）依赖作用范围<scope>

这个就是表示这个依赖会在哪里起作用，会不会进入最终的jar包吧，如果不配置默认是打进jar包的。

• compile，缺省值，适用于所有阶段，会打包进项目。
• provided，类似compile，期望JDK、容器或使用者会提供这个依赖。
• runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
• test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
• system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。