1. 情况一：
 
有代码的项目，打包类型一定不能为 pom。
 
pom一般只用于父工程，管理依赖，不写代码。
 
1. springboot项目的话，通常打成jar包。
 
2. 以前的那种SSM项目用tomcat启动war包的方式，才打war包。
 
如果有java代码的项目，用pom打包，则会导致其他项目依赖不上，从而报错： Could not find artifact com.wqm:tuantuan-common:jar:1.0-SNAPSHOT
 
所以：解决办法就是，定义pom.xml文件中的   <packaging>jar</packaging> 标签里面的类型,只要项目中有代码，那就定义jar  （默认就为jar，可以不定义）
 

  
 
 
 
 
情况二：
 
有代码的maven项目，通常要指定 maven编译环境，同时电脑的jdk环境，要与这插件的编译、打包环境一致。
 
不然有可能会出现一些问题，但不是绝对的。
 
通常报错: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project tuantuan-common: Fatal error compiling
 
比如： 
 
1. 电脑环境为jdk 8的环境，maven指定编译环境为11 ;   电脑jdk环境为jdk11，maven指定编译打包环境为13。   都是会出现这些错误的。
 
解决办法就是： 将电脑的jdk环境与maven指定的环境保持一致。
 
<build>
        <!-- 插件-->
        <plugins>
            <!-- java代码编译、打包插件: -->
            <!-- source： 指定使用jdk11进行编译-->
            <!-- target： 指定使用jdk11进行打包-->
            <!-- encoding： 指定编码为UTF-8-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>11</source>
                    <target>11</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
</build>
 
 
 
 
 
情况三：
 
有些springboot项目，是分模块的，比如domain单独分离成一个模块，然后依赖。有很多模块的情况中，里面可能存在多个main方法，这时候可能导致报错。
 
解决办法：
 
    <build>
        <plugins>
            <!-- Spring Boot的Maven插件（Spring Boot Maven plugin）能够以Maven的方式为应用提供Spring Boot的支持，即为Spring Boot应用提供了执行Maven操作的可能。-->
            <!-- Spring Boot Maven plugin能够将Spring Boot应用打包为可执行的jar或war文件，然后以通常的方式运行Spring Boot应用。-->
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <!-- 创建多模块 boot 项目，打包失败。-->
                    <!-- 因为 pom 集成了 boot-parent，打包时，在没有指定 mainClass 入口时，会找所有子模块下的 main 方法，除去 web 目录下有之外，其他模块下面均没有，导致打包异常。-->
                    <mainClass>com.wqm.gateway.TuantuanGatewayApplication</mainClass>
                </configuration>
                <executions>
                    <execution>
                        <id>repackage</id>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
 
就是指定要打成jar包的main方法的位置。
 
 
 
出现问题的原因举例：
 
比如说：
 
创建了一个 springboot项目：
 
里面的子模块项目结构如下：
 
springboot
       - controller
            - pom.xml
       - domain
            - pom.xml
       - common
            - pom.xml
       
 
按正常逻辑来说，controller模块里面有个main方法，就是springboot项目的入口。
 
但是现在，我们再common里面，写了一个utils，然后在utils里面，写了一个main方法做测试，这时候，controller也依赖了common项目，就会导致项目部署到服务器之后启动不成功。
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
完毕。
 
 

陈老师说了，没强调的意味着现在不要花精力去研究，会用即可。后面不断用它自然不就会了吗。
 
 
 
maven被陈老师讲完之后简直太特么简单了，以下是步骤：
 
1. eclipse- new project--maven 创建maven项目
 
2. 一直next即可，group id就是公司名，aritfactId就是模块名，version随便输入0.0.1或者1.0.0，package选你给我打成jar包，然后它会让你选模板，模板选一个quick-start，它就是包含一些基本的东西让我们快速开始。
 
以后要创建web或者其他项目，再选其他模板。
 
3. maven创建好了，怎么用呢？
 
比方说，你已经知道你打算用一个类了，那你肯定知道它的类名，现在把它的类名输入到 【maven central repo】https://search.maven.org 这个网址的搜索栏里，你就可以获得它的maven写法。
 
4. maven写法如下：
 
group id就是公司名
 
artifactId就是模块名、项目名
 
version就是版本号
 
<dependency>
   <groupId>ch.cern.hadoop</groupId>
   <artifactId>hadoop-common-project</artifactId>
   <version>2.7.5.1</version>
   <type>pom</type>
 </dependency>
 
dependency为什么会有type为pom，默认的值是什么？ 
 dependency中type默认为jar即引入一个特定的jar包。那么为什么还会有type为pom呢?当我们需要引入很多jar包的时候会导致pom.xml过大，我们可以想到的一种解决方案是定义一个父项目，但是父项目只有一个，也有可能导致父项目的pom.xml文件过大。这个时候我们引进来一个type为pom，意味着我们可以将所有的jar包打包成一个pom，然后我们依赖了pom，即可以下载下来所有依赖的jar包。
 
【简单来说就是把pom给你，jar包会自动被下载下来。】
 
5. maven工具使用（高级程序员都直接mvn package编译打包，不需要eclipse或者只把eclipse当成编辑器，就和用notepad一样）
 
你可以下载一个maven下来，无需安装直接解压。
 
然后你可以用Notepad直接写代码，或者选eclipse下面的一个项目。
 
代码或者项目准备好之后，
 
进cmd  cd到eclipse项目的目录下 比如c:\workspace\hdfs  
 
然后输入 c:\tools\maven\bin  mvn  package （如果你没设置mvn的环境变量，你就需要输入完整的bin目录来执行mvn）
 
进入到bin目录执行mvn（mvn的程序）package进行编译打包，编译大家都懂的，mvn package得到的结果是一个jar包。
 
编译完成的.class文件将会出现在target/classe目录下，具体文件夹就是c:work hdfs \target\hdfs-0.0.1.jar。
 
6. mvn其他命令
 
mvn install package 本地仓库中安装这个jar包（暂时还不懂有啥用）
 
mvn clean package 清除刚才生成的项目
 
7. fat jar
 
顾名思义就是胖包，就是把一个项目的文件和他所依赖的jar都打包成一个jar。
 
 
 
以下是fat.jar在maven的pom.xml中的实现（暂时没时间看，用到再说）
 
问题
 在使用“mvn package”命令编译application之后，生成的.jar文件不能直接被“java -jar”命令运行，一般都是因为： 
 1. Manifest中没有主清单属性。 
 2. 依赖项在.jar文件中不存在。
 
这两个问题可以通过在pom.xml中增加build plugin来解决。
 
方法1
 使用maven-assembly-plugin来打包fat-jar。
 
假设我们的application的Main Class是practice.spring.sprice.App，那么我们需要在pom.xml中增加如下一段：
 
<build>
     <plugins>
         <plugin>
             <artifactId>maven-assembly-plugin</artifactId>
             <version>3.0.0</version>
             <configuration>
                 <archive>
                     <manifest>
                         <mainClass>practice.spring.sprice.App</mainClass>
                     </manifest>
                 </archive>
                 <descriptorRefs>
                     <descriptorRef>jar-with-dependencies</descriptorRef>
                 </descriptorRefs>
             </configuration>
             <executions>
                 <execution>
                     <id>make-assembly</id>
                     <phase>package</phase>
                     <goals>
                         <goal>single</goal>
                     </goals>
                 </execution>
             </executions>
         </plugin>
     </plugins>
 </build>

 这种方法打包出来的.jar中： 
 1. practice.spring.sprice.App会被作为主类。 
 2. 包含所依赖的所有jar的内容（这些jar包会被解开）。
 
方法2
 使用spring-boot-maven-plugin来打包fat-jar。 
 在pom.xml中增加如下一段：
 
<build>
     <plugins>
         <plugin>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-maven-plugin</artifactId>
             <version>1.5.6.RELEASE</version>
             <executions>
                 <execution>
                     <goals>
                         <goal>repackage</goal>
                     </goals>
                 </execution>
             </executions>
         </plugin>
     </plugins>
 </build>

 这种方法打包出来的.jar中： 
 1. org.springframework.boot.loader.JarLauncher会被作为主类，它会自动调用应用程序中的main方法。 
 2. 包含所依赖的所有的jar包（这些jar包不会被解开）
  
 
 

 
 
maven 打包编译
 

  

   
  
 
 
 
 像你们中的许多人一样，我正在使用多模块Maven项目 。 与现有的许多系统相比，它不是一个巨大的系统，它具有15个模块，3种不同的耳朵部署，带有属性文件的大量参数化以及大约10万行Java代码。 在开发高峰期，由于代码的遗留来源，因此代码需要大量重构，因此需要为每个开发人员进行连续的编译/打包和部署。 
 
 
 尽管这些年来学习难度很大，但我还是接受了Maven及其哲学。 我并不是说这是完美的，但我真的相信这是一个很好的工具，仍然有用，尤其是当您的项目和团队随着项目的增长而增长时。 （尽管这篇文章不是关于Maven传福音的）。 
 
 
 因此，我们团队的问题之一是，尽管切换了正确的标志 ，将代码破坏并打包到模块中，使用配置文件和maven提供的所有“工具”，我们的构建和打包时间却开始缓慢增加，彻底清洁后达到1分钟的阈值。 我们的主要编译器是Sun / Oracle Javac，其时间是通过命令行打包而不是通过IDE进行监视的，您可以在其中看到不同的时间，具体取决于“ Maven集成”和每种工具调用的内部编译器。 [我的参考机器是我的旧款MacBookPro 2009，Core 2 Duo 2.5，具有Vertex 3 SSD（启用了Trim）] 
 
 
 最近，当我浏览Jason Van Zyl （ 他是Maven的父亲 ）的Twitter帐户时，我发现了takari生命周期插件 。 Jason和他的团队正在为Maven生态系统创建工具和插件，我希望将Maven社区多年来寻求的Maven生态系统带来人们期待已久的发展。 
 
 
 简而言之，takari生命周期插件是Maven生命周期的一种替代实现，它将5个不同的插件合而为一。 一旦激活它，它将接管并调用以下5种实现： 
 
 
 资源插件 
 编译器插件 
 jar插件 
 安装插件 
 部署插件 
 
 
 你可以在这里阅读。 至少在我看来，最棒的是编译器插件，该插件在内部实施增量编译策略，该策略基于可检测源文件和资源更改的机制！ 
 
 
 为了理解差异，当在您的maven构建中使用takari编译器插件与经典编译器插件和javac（您中很多人可能会使用）进行比较时，我将共享此博客文章中的表格（解释增量编译） ）。 
 
 
  
 显然，如果您选择调用JDT而不是Javac，结果将更好。 当前，我们坚持使用Javac ，但是上图使我在IntelliJ IDE上更改了默认编译器，尤其是当我进行重构和更改时，与Javac相比， JDT在增量编译方面要好得多。 
 
 
安全吗
 
 
 好吧，就我而言（我想在那里有很多人），我只是按照建议的方式 
 在这里 。 我在父pom中激活了插件，然后将所有jar模块的包装类型更改为'takari-jar'。 
 
 
takari-jar
 
 事实并非如此，最终更改是如此容易，您可以将其还原。 
 
 
 我在git repo上推送了takari生命周期更改的那一天，半小时后，我开始听到团队成员的“哇”和“ yeees”。 更改后重新打包非常便宜，对资源文件和属性的更改确保了我们在需要时可以获取新的软件包。 我们的重新包装时间减少到50％-60％以上。 
 
 
 如果您碰巧在Maven版本中遇到相同的问题，我强烈建议您尝试takari一天的时间–这将使您和您的团队花费大量时间。 
 
 
 我还想指出，takari是免费的，尽管事实上takari团队是为一个不知名的“大”客户开发和更新的，但该团队可以免费免费赠送它并与社区共享。 所以非常感谢您！！！该插件可以在maven Central中找到。 
 
 
 takari小组正在每周进行一次Google hangout ，信息可以在这里找到，我很抱歉我还没有参加，也许很早就参加了。 
 
 
 所以去Maven！ 高隆！ 
 
 

  
翻译自: https://www.javacodegeeks.com/2014/11/do-you-really-want-to-speed-up-your-maven-compilepackaging-then-takari-lifecycle-plugin-is-the-answer.html
 
 
maven 打包编译

1、DepencyManagement应用场景
 
         当我们的项目模块很多的时候，我们使用Maven管理项目非常方便，帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。
 
         由于我们的模块很多，所以我们又抽象了一层，抽出一个itoo-base-parent来管理子项目的公共的依赖。为了项目的正确运行，必须让所有的子项目使用依赖项的统一版本，必须确保应用的各个项目的依赖项和版本一致，才能保证测试的和发布的是相同的结果。
 
        在我们项目顶层的POM文件中，我们会看到dependencyManagement元素。通过它元素来管理jar包的版本，让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号。
 
 
 
来看看我们项目中的应用：
 
                                                                                              pom继承关系图：
 
 
                                                                     依赖关系：
 
Itoo-base-parent(pom.xml)
 
<dependencyManagement>  
          
        <dependencies>  
            <dependency>  
                <groupId>org.eclipse.persistence</groupId>  
                <artifactId>org.eclipse.persistence.jpa</artifactId>  
                <version>${org.eclipse.persistence.jpa.version}</version>  
                <scope>provided</scope>  
            </dependency>  
              
            <dependency>  
                <groupId>javax</groupId>  
                <artifactId>javaee-api</artifactId>  
                <version>${javaee-api.version}</version>  
            </dependency>  
        </dependencies>  
    </dependencyManagement>  
 
 
 
Itoo-base(pom.xml)
 
<!--继承父类-->  
<parent>  
        <artifactId>itoo-base-parent</artifactId>  
        <groupId>com.tgb</groupId>  
  
        <version>0.0.1-SNAPSHOT</version>  
        <relativePath>../itoo-base-parent/pom.xml</relativePath>  
    </parent>  
        <modelVersion>4.0.0</modelVersion>  
        <artifactId>itoo-base</artifactId>  
        <packaging>ejb</packaging>  
          
        <!--依赖关系-->  
        <dependencies>  
        <dependency>  
            <groupId>javax</groupId>  
            <artifactId>javaee-api</artifactId>  
        </dependency>  
          
        <dependency>  
            <groupId>com.fasterxml.jackson.core</groupId>  
            <artifactId>jackson-annotations</artifactId>  
        </dependency>  
          
        <dependency>  
            <groupId>org.eclipse.persistence</groupId>  
            <artifactId>org.eclipse.persistence.jpa</artifactId>  
            <scope>provided</scope>  
        </dependency>  
    </dependencies>  
</project>  
 
 
 
         这样做的好处：统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，才能保证测试的和发布的是相同的成果，因此，在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个版本号时，只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。
 
2、Dependencies
 
       相对于dependencyManagement，所有生命在dependencies里的依赖都会自动引入，并默认被所有的子项目继承。
 
3、区别
 
           dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）
 
         dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。
 
 
 
4、Maven约定优于配置
 
       它提出这一概念，为项目提供合理的默认行为，无需不必要的配置。提供了默认的目录
 
 
 
src                   ——>         源代码和测试代码的根目录
 
main                            应用代码的源目录
 
Java                     源代码
 
resources           项目的资源文件
 
test                               测试代码的源目录
 
java                      测试代码
 
resources            测试的资源文件
 
target                                   编译后的类文件、jar文件等
 
 
 
        对于Maven约定优于配置的理解，一方面对于小型项目基本满足我们的需要基本不需要自己配置东西，使用Maven已经配置好的，快速上手，学习成本降低；另一方面，对于不满足我们需要的还可以自定义设置，体现了灵活性。配置大量减少了，随着项目变的越复杂，这种优势就越明显。
 
总结区别：
 
         <dependencies>中的jar直接加到项目中，管理的是依赖关系（如果有父pom,子pom,则子pom中只能被动接受父类的版本）；<dependencyManagement>主要管理版本，对于子类继承同一个父类是很有用的，集中管理依赖版本不添加依赖关系，对于其中定义的版本，子pom不一定要继承父pom所定义的版本。