IntelliJ Idea14 create a multi-module Maven project, multiple inheritance, hot deployment configuration summary (b)

Further to the above [ IntelliJ Idea14 create multi-module Maven project, multiple inheritance, hot deployment configuration summary (a) ], summarize some of the points deployment projects under heat and pom file structure:

First, the hot deployment dependencies

If the above items changed service service code dependencies core module, restart the web server can not see the effect of the changes, because the dependence of core has been labeled jar contracted web module uses, reboot and will not play again jar package, we can only re-package package to see the results.
[Solution]: the dependence of the core module, which is compiled into the web module to generate core of the class files in the web, so the compiler will restart the Live Update interface.
[Untreated] before:
Here Insert Picture Description
Configuration module output layoutunder class, select the corresponding dependent on right-click on put into output root

[after processing, repackaging, start]:

Once you have class files, restart the service will be able to see the changes.

In addition Project Stucturethere is also some other points to note:
1, [Modules] when the project JDK 1.8 when the configuration of each module的Language Levelof the JDK level corresponding to;

2, [] Facets
check Facets right of [ Deplyment Descriptors], must be a point to web.xml
check Facets right of [ Web Resource Directories], must be selected webappdirectories, similar to ordinary non-maven project needs to point WebRoot or WebContent directory

3, [Artifacts] is above the hot deployment configuration.

Two, pom configuration essentials

2.1 pom inheritance

1, layer by layer Project module can inherit it, such as multi-level module method:

module-test
--- module-test-common
--- module-test-platform
--- --- module-test-platform-A
--- --- module-test-platform-B

From the result:

module-test-platform-A和module-test-platform-B的parent是module-test-platform
module-test-platform和module-test-common的parent是module-test

上面配置要实现的话，也很简单，只需要将module-test-platform的pom.xml里面配置成<packaging>pom</packaging>，然后module-test-platform-A和module-test-platform-B的parent都以来module-test-platform的GAV（maven三要素：groupId/artifactId/version）就行了。

<packaging>不写的话默认是jar，意思就是打成jar包；
写pom的意思就是做父模块，给子模块继承或者引用；
写war的意思就是打成war包给tomcat启动；

在Maven 中除了用继承parent来做版本控制以外, 还可以通过 scope=import 来做版本控制.

Maven 2.0.9 添加了一个新特性: scope = import 也就是从外部导入依赖管理的依赖配置. 使用过 DependencyManagement都知道, 多模块构建项目的时候, 为了解决各模块依赖版本一致, 统一在父pom.xml文件中统一定义各个依赖jar文件的版本, 然后子模块通过引用的方式添加需要的依赖jar, 但随着项目工程越来越大, 添加的依赖文件也越来也多, 父pom.xml的 DependencyManagement 也会越来越长, 不便于管理. 另外, 因为pom.xml 是单继承的, 如果已经有一个父pom.xml了, 想要再引用外部的pom.xml, 就只能复制到父pom.xml中了. 因此采用在 DependencyManagement 中使用scope = import的方式可以分类引入更多的管理配置, 也摆脱了单继承的限制.

使用import scope解决maven继承（单）问题

想必大家在做SpringBoot应用的时候，都会有如下代码：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.3.3.RELEASE</version>
</parent>

继承一个父模块，然后再引入相应的依赖

假如说，我不想继承，或者我想继承多个，怎么做？

我们知道Maven的继承和Java的继承一样，是无法实现多重继承的，如果10个、20个甚至更多模块继承自同一个模块，那么按照我们之前的做法，这个父模块的dependencyManagement会包含大量的依赖。如果你想把这些依赖分类以更清晰的管理，那就不可能了，import scope依赖能解决这个问题。你可以把dependencyManagement放到单独的专门用来管理依赖的pom中，然后在需要使用依赖的模块中通过import scope依赖，就可以引入dependencyManagement。例如可以写这样一个用于依赖管理的pom：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.test.sample</groupId>
    <artifactId>base-parent1</artifactId>
    <packaging>pom</packaging>
    <version>1.0.0-SNAPSHOT</version>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactid>junit</artifactId>
                <version>4.8.2</version>
            </dependency>
            <dependency>
                <groupId>log4j</groupId>
                <artifactid>log4j</artifactId>
                <version>1.2.16</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

然后我就可以通过非继承的方式来引入这段依赖管理配置

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.test.sample</groupId>
            <artifactid>base-parent1</artifactId>
            <version>1.0.0-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
 
<dependency>
    <groupId>junit</groupId>
    <artifactid>junit</artifactId>
</dependency>
<dependency>
    <groupId>log4j</groupId>
    <artifactid>log4j</artifactId>
</dependency>

注意：import scope只能用在dependencyManagement里面

这样，父模块的pom就会非常干净，由专门的packaging为pom来管理依赖，也契合的面向对象设计中的单一职责原则。此外，我们还能够创建多个这样的依赖管理pom，以更细化的方式管理依赖。这种做法与面向对象设计中使用组合而非继承也有点相似的味道。

那么，如何用这个方法来解决SpringBoot的那个继承问题呢？

配置如下：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>1.3.3.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
 
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

这样配置的话，自己的项目里面就不需要继承SpringBoot的module了，而可以继承自己项目的module了。

参考：https://blog.csdn.net/mn960mn/article/details/50894022

2.2 dependencies与dependencyManagement的区别

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

这样做的好处：统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，才能保证测试的和发布的是相同的成果，因此，在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个版本号时，只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。

区别：

dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）

dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

2.3 Maven依赖Scope选项详解

在一个maven项目中，如果存在编译需要而发布不需要的jar包，可以用scope标签，值设为provided。

如下：

<dependency>
  <groupId>javax.servlet.jsp</groupId>
  <artifactId>jsp-api</artifactId>
  <version>2.3</version>
  <scope>provided</scope>      
</dependency>

Scope的其他参数如下：

compile：默认的scope，表示 dependency 都可以在生命周期中使用。
而且，这些dependencies 会传递到依赖的项目中。适用于所有阶段，会随着项目一起发布

provided：跟compile相似，但是表明了dependency 由JDK或者容器提供，例如Servlet AP和一些Java EE APIs。这个scope 只能作用在编译和测试时，同时没有传递性，即：child module无法引用。

runtime：表示dependency不作用在编译时，但会作用在运行和测试时，如JDBC驱动，适用运行和测试阶段，与provided相反。

test：表示dependency作用在测试时，不作用在运行时。只在测试时使用，用于编译和运行测试代码。不会随项目发布。

system：跟provided 相似，但是在系统中要以外部JAR包的形式提供，maven不会在repository查找它。

2.4 Maven的classifier作用

classifier can be any string, for determining the splicing GAV specified in the file later.
It can be used to distinguish different packets jar jdk versions generated

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <version>2.2.2</version>  
    <classifier>jdk15</classifier>    
</dependency>

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <version>2.2.2</version>  
    <classifier>jdk13</classifier>    
</dependency>

Jar package is actually corresponds to json-lib-2.2.2-jdk15.jarand json-lib-2.2.2-jdk13.jar.

Distinguish between different components of the project, for example: source code, Javadoc, class files.

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <version>2.2.2</version>  
    <classifier>jdk15-javadoc</classifier>    
</dependency>

It corresponds json-lib-2.2.2-jdk15-javadoc.jar.

Note classifier location

<dependency>  
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>   
    <classifier>jdk15-javadoc</classifier>  
    <version>2.2.2</version>   
</dependency>

It corresponds json-lib-jdk15-javadoc-2.2.2.jar. You can not find the jar package may occur.