Maven集成日志和依赖域Scope

一、日志依赖的冲突

• 在使用一些第三方包的时候，比如zkClient包的时候，这些包往往都封装了对日志组件的依赖，但是我们注意看，他依赖的部分的生命周期是不一样的，如下(非关键部分为贴出)：

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.6.1</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.6.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.15</version>
      <scope>test</scope>
    </dependency>

• 我们看到除了slf4j-api之外，其余的部分依赖的scope是test，也就是说这些依赖在编译测试的时候有效，在运行的时候是无效的。这里包的作用如下：

slf4j-api:日志门面接口
slf4j-log4j12：log4j对接门面接口的桥接
log4j：log4j的真正日志实现

• 换言之，zkClient在编译阶段引入了全部的日志功能，但是运行阶段并没有依赖log4j组件,所以我在不添加任何日志依赖的时候，打印日志会提示没有日志组件绑定。

• 现在我需要自己依赖log4j2，需要怎么办呢，我直接添加下面的依赖发现运行会报错，提示slf4j有多个绑定。

<dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>${log4j2.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>${log4j2.version}</version>
        </dependency>
        <dependency>
            <!--<groupId>org.apache.logging.log4j</groupId>-->
            <!--<artifactId>log4j-slf4j-impl</artifactId>-->
            <!--<version>${log4j2.version}</version>-->
        </dependency>

• 研究发现是因为slf4j接口有多个绑定导致的。于是我将zkClient里面的slf4j-log4j12排除，就可以启动了。到此可知slf4j-api在编译阶段只能绑定一种实现，只能在log4j-slf4j-impl和slf4j-log4j12之间选择一个(分别绑定log4j2和log4j)。

<dependency>
            <groupId>com.101tec</groupId>
            <artifactId>zkclient</artifactId>
            <version>0.10</version>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

二、Maven中依赖的域

• import、provided、runtime、compile、system、test

1.compile(默认)

在编译的时候将这个依赖加入进来，并且打包的时候也会将依赖加入进去,意思就是：编译
范围有效，在编译与打包时都会存储进去。

2.provided

在编译和测试的时候有效，在打包时候不会加入，别的设施(Web Container)会提供。
比如：servlet-api，因为在tomcat等web服务器中已经存在该包，如果在打包进去，那么包之间就会冲突。 事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。

3.test

表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如junit。

4.runtime

runntime表示被依赖项目无需参与项目的编译，在运行的时候才会依赖,不过后期的测试和运行周期需要其参与。与compile相比，跳过编译而已，说实话在终端的项目（非开源，企业内部系统）中，和compile区别不是很大。比较常见的如JSR×××的实现，对应的APIjar是compile的，具体实现是runtime的，compile只需要知道接口就足够了。oracle jdbc驱动架包就是一个很好的例子，一般scope为runntime。另外runntime的依赖通常和optional搭配使用，optional为true。我可以用A实现，也可以用B实现。

5.system

从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用。

三、Scope的依赖传递

A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是：
当C是test或者provided时，C直接被丢弃，A不依赖C；
否则A依赖C，C的scope继承于B的scope。

x	x	x	x	x
—	compile	provided	runtime	test
compile	compile	-	runtime	-
provided	provided	-	provided	-
runtime	runtime	-	runtime	-
test	test	-	test	-

四、小Demo

• 假如我在一个项目中同事依赖了slf4j-log4j12和log4j-slf4j-impl，如下，那么编译不会通过，可以自己尝试一下，将其中一个Scop配置为provide，另一个配置为runtime，就可以了，因为前者会参与编译过程，后者则不会参与编译。

    <properties>
        <log4j2.version>2.4.1</log4j2.version>
        <slf4j.version>1.7.12</slf4j.version>
    </properties>
    
<dependencies>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.6.1</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>${log4j2.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>${log4j2.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>${log4j2.version}</version>
            <scope>runtime</scope>
        </dependency>
    </dependencies>