精华内容
下载资源
问答
  • maven依赖范围 -maven scope -compile依赖范围 -test依赖范围 -provided范围依赖
    千次阅读
    2020-04-06 20:20:11

    目录

    一、在pom.xml中dependencies节点引用我们所需要的依赖

    二、scope节点指定依赖范围,常见的依赖范围有三种:compile(默认)、test、provided

    从三个方面看这三种依赖范围的区别

    maven项目的标准目录结构

    三种依赖范围的区别

    原因分析

    三、Tips

    四、其它maven相关博客


    一、在pom.xml中dependencies节点引用我们所需要的依赖

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
       
        <groupId>xin.yangshuai</groupId>
        <artifactId>Hello</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        
        <name>Hello</name>
        <description>Demo project for Hello</description>
    
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.0</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </project>

    二、scope节点指定依赖范围,常见的依赖范围有三种:compile(默认)、test、provided

    1. 从三个方面看这三种依赖范围的区别

      1. 是否对主程序有效(main目录下的程序):主程序代码是否可以引用这个依赖
      2. 是否对测试程序有效(test目录下的程序):测试程序是否可以引用这个依赖
      3. 是否参与打包(部署):打包(package)后,这个依赖是否会被打到包内(lib文件夹内)
    2. maven项目的标准目录结构

      Hello
      |---src
      |---|---main
      |---|---|---java
      |---|---|---resources
      |---|---test
      |---|---|---java
      |---|---|---resources
      |---pom.xml

       

    3. 三种依赖范围的区别

      依赖范围(scope)是否对主程序有效是否对测试程序有效是否参与打包(部署)典型例子
      compile有效有效参与spring-core
      test无效有效不参与junit
      provided有效有效不参与servlet-api.jar
      1. 测试程序常规情况下是不参与打包的

    4. 原因分析

      1. compile依赖范围:默认的依赖范围,开发时需要,部署时也需要(运行时servlet容器不会提供),一般的就是这样。
      2. test依赖范围:主程序(main)是无法依赖test范围的jar的,开发时就不可以(那些jar主程序也是用不到的),只有测试程序可以依赖。要知道,测试程序常规是不会参与打包的,test范围的依赖也不参与打包,只是在开发阶段会用到,或者maven编译(compile)时会执行测试程序。
        1. 如果开发时主程序可以依赖test范围的jar,那么打包时由于test范围的jar不参与打包,所以打成的包运行时肯定就会报错。
      3. provided范围依赖:开发时,由于没有运行时环境,有些jar我们需要暂时依赖(不依赖有些方法就会找不到,用不了),但是项目打包部署运行时,由于运行时环境(servlet容器,比如:tomcat)会提供一些jar包,所以开发时那些暂时依赖的jar包就不能参与打包了,否则会发生冲突导致报错。

    三、Tips

    1. 如有不对的地方还请告知,感激不尽

    2. 整体内容参考视频教程:http://www.gulixueyuan.com/my/course/42

    四、其它maven相关博客

    1. maven依赖范围:https://blog.csdn.net/shuair/article/details/105350415
    2. maven依赖传递性:https://blog.csdn.net/shuair/article/details/105401296
    3. maven统一依赖版本号:https://blog.csdn.net/shuair/article/details/105404764
    4. maven聚合:https://blog.csdn.net/shuair/article/details/105416365

     

    更多相关内容
  • Maven 一个核心的特性就是依赖管理。当我们处理一个或多模块的项目时,模块间的依赖关系就变得非常复杂,管理也变得很困难。针对此种情形,Maven 提供了一种高度控制的方法。 一、依赖配置 依赖是 Maven中最关键...

           Maven 一个核心的特性就是依赖管理。当我们处理一个或多模块的项目时,模块间的依赖关系就变得非常复杂,管理也变得很困难。针对此种情形,Maven 提供了一种高度控制的方法。

    一、依赖配置

           依赖是 Maven中最关键的部分,我们之所以在工程中使用Maven,就是因为它的依赖管理功能。如果我们想要在工程中引入某个jar 包,只需要在 pom.xml 中引入其 jar包的坐标即可。

    <project>
        ...
        <dependencies>
            <dependency>
                <groupId>...</groupId>
                <artifactId>...</artifactId>
                <version>...</version>
                <type>...</type>
                <scope>...</scope>
                <optional>...</optional>
                <exclusions>
                    <exclusion>
                    ...
                    </exclusion>
                </exclusions>
            </dependency>
            ...
        </dependencies>
        ...
    </project>

        1、groupId、artifactId和version:依赖的基本坐标,对于任何一个依赖来说,基本坐标是最重要的,Maven根据坐标才能找到需要的依赖;

        2、type:依赖的类型,对应于项目坐标定义的packaging,大部分情况下,该元素不必声明,其默认值为jar;

        3、scope:依赖的范围,这个内容就比较多一点;

        4、optional:标记依赖是否可选;

        5、exclusions:用来排除传递性依赖。

    很多时候,大部分依赖声明只包含groupId、artifactId和version这三个指定基本坐标的元素;而在一些特殊情况下,其它元素至关重要。

    二、依赖范围

           依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系。

           Maven 提供了六种依赖的范围:compile、test、provided、runtime、system 和import。其中compile 是默认的依赖范围。

    在Maven中,我们可以针对 scope要素设置以下依赖范围:

          1、compile编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的maven依赖,对于编译 测试 运行三种的classpath都有效。

          2、test测试依赖范围。使用此依赖范围的Maven依赖,只对于测试的classpath有效,在编译主代码或者运行主代码的时候都无法依赖此类依赖。典型的例子是jUnit,它只有在编译测试代码及运行测试代码的时候才有效

          3、provided:以提供依赖范围。使用此依赖范围的maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行的时候,由于容器已经提供,就不需要maven重复地引入一遍。打包的时候可以不用包进去,别的设施会提供。事实上该依赖理论上可以参与编译,测试,运行等周期。相当于compile,但是打包阶段做了exclude操作

          4、runtime:运行时依赖范围。使用此依赖范围的maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要jdk提供的jdbc的接口,只有在执行测试或者运行测试的时候才需要实现上述接口的jdbc的驱动

          5、system:系统依赖范围。从参与度来说,和provided相同,不过被依赖项不会从maven仓库下载,而是从本地文件系统拿。需要添加systemPath的属性来定义路径,该依赖与三种范围的classpath,和provided依赖范围完全一致。可能造成不可移植,谨慎使用。

          6、import:导入依赖范围。该依赖范围不会对三种classpath产生实际影响。只有在dependencyManagement下才有效果。

    三、依赖传递性

     1、传递性依赖范围

           在传递性依赖中,假设A依赖B,B依赖C,我们就说A与B是第一直接依赖,B与C是第二直接依赖,C对于A是传递性依赖。

    第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围,下面通过一张表格来说明这种传递性依赖范围:

      

         传递性依赖的前提条件是 scope的值为compile

    2、A依赖B,B依赖C。当前项目为A,只当B在A项目中的scope,那么c在A中的scope是如何得知呢?

          当C是test或者provided时,C直接被丢弃,A不依赖C;(排除传递依赖),

           否则A依赖C,C的scope继承与B的scope。maven会解析各个依赖的pom,将那些必要的间接依赖,一传递性依赖的形式引入到当前的项目中。

    3、多个Maven项目(模块)之间如何依赖

         比如:A项目依赖B项目

           1)将 B项目 install 到本地仓库,供其他项目使用。

           2)在 A项目的pom.xml 引入B项目的依赖(gav)即可使用。

    四、依赖排除

            exclusions标签可以包含一个多个exclusion元素,可以排除一个或多个依赖。声明exclusion的时候只需要groupId和artifactId,而不需要version元素。通过引入spring-context依赖演示:

    1、引入spring-context依赖,默认包含了beans、core等依赖。

          

    2、引入spring-context依赖,排除beans、core依赖。

          

    五、依赖原则:为了防止jar包冲突

            由于依赖的内容存在多个版本,如果出现某一个POM依赖多个版本时,则称之为依赖冲突

    依赖冲突遵循两个原则:

    1、最短路径优先原则(依赖的内容,传递次数越小越优先)

          如果 A依赖于B,B依赖于C,在 B和 C中同时有 log4j的依赖,并且这两个版本不一致时,那么 A会根据最短路径优先原则,在 A中会传递过来 B的log4j版本。或者 通过2- 2)一起演示:

        

    2、路径相同时分两种情况

        1)在同一个 pom.xml文件中有两个相同的依赖:后声明则优先(会覆盖前面的),严禁使用

            比如:A项目依赖 spring-context

            

        2)不在同一个 pom.xml文件中有两个相同的依赖:前声明则优先(会覆盖后面的)

            比如:A项目依赖B项目(B依赖 spring-context-5.0.6),同时A项目依赖C项目(C依赖 spring-context-5.0.8)

            将 B、C项目 install 到本地仓库,供A项目使用

             

              

    六、统一JDK版本

    两种方式

    1、通过项目properties右击设置     

    2、通过 pom.xml 文件设置

    	<build>
    		<finalName>comparison-data-project</finalName>
    		<plugins>
    			<plugin>
    				<groupId>org.apache.maven.plugins</groupId>
    				<artifactId>maven-compiler-plugin</artifactId>
    				<version>3.5.1</version>
    				<configuration>
    					<source>1.8</source>
    					<target>1.8</target>
    				</configuration>
    			</plugin>
    		</plugins>
    	</build>

       3、通过修改setting文件,即可,创建Maven项目就用配置好的那个JDK,之前见过

    七、统一jar包版本管理

          在 pom.xml使用 properties标签定义一些常量, 方便管理Jar包版本,通过类似 el表达式访问。

          

     

        在使用Maven时,只是简单知道Maven的用法,从而忽略了其中的一些细节。这里整理下。

    ends~

     

    展开全文
  • Maven 依赖范围

    万次阅读 多人点赞 2018-01-18 11:57:42
    1.什么是依赖范围?maven 项目不同的阶段引入到classpath中的依赖是不同的,例如,编译时,maven 会将与编译相关的依赖引入classpath中,测试时,maven会将测试相关的的依赖引入到classpath中,运行时,maven会将与...

    1.什么是依赖范围?

    maven 项目不同的阶段引入到classpath中的依赖是不同的,例如,编译时,maven 会将与编译相关的依赖引入classpath中,测试时,maven会将测试相关的的依赖引入到classpath中,运行时,maven会将与运行相关的依赖引入classpath中,而依赖范围就是用来控制依赖于这三种classpath的关系。 

    2.依赖范围在pom.xml中如何体现? 

    pom文件如下配置:

        <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.7</version>
       <scope>test</scope>
        </dependency>

    其scope标签就是依赖范围的配置,默认是compile,可选配置有test、provided、runtime、system、import

    2.有哪些依赖范围?

    既<scope>标签的可选配置:compile、test、provided、runtime、system、import,下面一一介绍

    1)编译依赖范围(compile),该范围就是默认依赖范围,此依赖范围对 于编译、测试、运行三种classpath都有效,举个简单的例子,假如项目中有spring-core的依赖,那么spring-core不管是在编译,测试,还是运行都会被用到,因此spring-core必须是编译范围(构件默认的是编译范围,所以依赖范围是编译范围的无须显示指定)

         <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring-core</artifactId>
         <version>2.5</version>
         <scope>compile</scope> <!--默认为该依赖范围,无须显示指定--〉
        </dependency>

    2)测试依赖范围(test),顾名思义就是针对于测试的,使用此依赖范围的依赖,只对测试classpath有效,在编译主代码和项目运行时,都将无法使用该依赖,最典型的例子就是 Junit, 构件在测试时才需要,所以它的依赖范围是测试,因此它的依赖范围需要显示指定为<scope>test</scope> ,当然不显示指定依赖范围也不会报错,但是该依赖会被加入到编译和运行的classpath中,造成不必要的浪费 。

     <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>4.7</version>
        <scope>test</scope>
        </dependency>

    3)已提供依赖范围(provided),使用该依赖范围的maven依赖,只对编译和测试的classpath有效,对运行的classpath无效,典型的例子就是servlet-api, 编译和测试该项目的时候需要该依赖,但是在运行时,web容器已经提供的该依赖,所以运行时就不再需要此依赖,如果不显示指定该依赖范围,并且容器依赖的版本和maven依赖的版本不一致的话,可能会引起版本冲突,造成不良影响。

     <dependency>
         <groupId>javax-servlet</groupId>
         <artifactId>servlet-api</artifactId>
         <version>2.0</version>
        <scope>provided</scope>
        </dependency>

    4)运行时依赖范围(runtime),使用该依赖范围的maven依赖,只对测试和运行的classpath有效,对编译的classpath无效,典型例子就是JDBC的驱动实现,项目主代码编译的时候只需要JDK提供的JDBC接口,只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。

    5),系统依赖范围(system),该依赖与classpath的关系与 provided依赖范围完全一致,但是系统依赖范围必须通过配置systemPath元素来显示指定依赖文件的路径,此类依赖不是由maven仓库解析的,而且往往与本机系统绑定,可能造成构件的不可移植,因此谨慎使用,systemPath元素可以引用环境变量:

            <dependency>
        <groupId>javax.sql</groupId>
        <artifactId>jdbc-stext</artifactId>
        <version>2.0</version>
        <scope>system</scope>
        <systemPath>${java.home}/lib/rt.jar</systemPath> 
        </dependency>

    6)导入依赖范围(import),该依赖范围不会对三种classpath产生影响,该依赖范围只能与dependencyManagement元素配合使用,其功能为将目标pom文件中dependencyManagement的配置导入合并到当前pom的dependencyManagement中。有关dependencyManagement的功能请了解maven继承特性。



    展开全文
  • maven的依赖范围 ①. maven的依赖范围包括:compile、provide、runtime、test、system compile:编译范围的依赖会用在编译,测试,运行,由于运行时需要,所以编译范围的依赖会被打包(会被打包) test:test范围依赖在...

    ①. Maven的依赖范围

    • ①. maven的依赖范围包括:compile、provide、runtime、test、system
    1. compile:编译范围的依赖会用在编译,测试,运行,由于运行时需要,所以编译范围的依赖会被打包(会被打包)
    2. test:test范围依赖在编译和运行时都不需要,只在测试编译和测试运行时需要。例如:Junit。由于运行时不需要,所以test范围依赖不会被打包(不会打包)
    3. provide:provide依赖只有当jdk或者一个容器已提供该依赖之后才使用。provide依赖在编译和测试时需要,在运行时不需要。例如:servletapi被Tomcat容器提供了(不会打包)
    4. runtime:runtime依赖在运行和测试系统时需要,但在编译时不需要。例如:jdbc的驱动包。由于运行时需要,所以runtime范围的依赖会被打包(会打包)
    5. system:system范围依赖与provide类似,但是必须显示的提供一个对于本地系统中jar文件的路径。一般不推荐使用
    • ②. 图解
      在这里插入图片描述
    • ③. 代码中展示:
    		<!--导入mysql驱动-->
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
    			<!--runtime表示编译器不使用它,运行期使用它-->
    			<scope>runtime</scope>
                <version>8.0.17</version>
            </dependency>
            <!--导入servlet相关依赖,request不报错-->
            <dependency>
                <groupId>javax.servlet</groupId>
                <artifactId>servlet-api</artifactId>
                <version>2.5</version>
    			<!--provided的意思是编译时使用它,运行时不使用-->
                <scope>provided</scope>
            </dependency>
    		<--jsp-->	
    		<dependency>
    		  <groupId>javax.servlet.jsp</groupId>
    		  <artifactId>jsp-api</artifactId>
    		  <version>2.0</version>
    		  <scope>provided</scope>
    		</dependency>
    		<!--system 编译测试有用、不会运行打成jar-->
    		<dependency>
                <groupId>com.sun</groupId>
                <artifactId>tools</artifactId>
                <scope>system</scope>
                <optional>true</optional>
                <version>${java.version}</version>
                <systemPath>${java.home}/../lib/tools.jar</systemPath>
            </dependency>
    

    ②. Maven的常用设置

    ①. 全局变量

    • ①. 在Maven的pom.xml文件中,properties用于定义全局变量,POM中通过${property_name}的形式引用变量的值。定义全局变量:
    	<properties>
    		<spring.version>4.3.10.RELEASE</spring.version>
    	</properties>
    
    • ②. 引用全局变量:
    	<dependency>
    		<groupId>org.springframework</groupId>
    		<artifactId>spring-context</artifactId>
    		<version>${spring.version}</version>
    	</dependency>
    

    ②. Maven系统采用的变量

    <properties>
    	<!--源码编译jdk版本-->		
    	<maven.compiler.source>1.8</maven.compiler.source>
    	<!--运行代码的jdk版本-->
    	<maven.compiler.target>1.8</maven.compiler.target>
    	<!--项目构建使用的编码,避免中文乱码-->
    	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    	<!--生成报告的编码-->
    	<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    </properties>
    

    ③. 指定资源位置

    • ①. src/main/java和src/test/java这两个目录中的所有*.java文件会分别在comile和test-comiple阶段被编译,编译结果分别放到了target/classes和targe/test-classes目录中,但是这两个目录中的其他文件都会被忽略掉,如果需要把src目录下的文件包放到target/classes目录,作为输出的jar一部分。需要指定资源文件位置。以下内容放到buid标签中

    • ②. IDEA中图解(默认情况下)
      在classes中没有A.txt文件出现

    在这里插入图片描述

    • ③. 需求一:想要A.txt出现在classes中
      在pom.xml添加如下内容,然后重新打包即可
    	<build>
    	     <resources>
    	         <resource>
    	             <!--所在的目录-->
    	             <directory>src/main/java</directory>
    	             <includes>
    	                 <!--包括目录下的.properties,.xml 文件都会扫描到-->
    	                 <include>**/*.properties</include>
    	                 <include>**/*.xml</include>
    	                 <include>**/*.txt</include>
    	             </includes>
    	             <!--filtering 选项 false 不启用过滤器, *.property 已经起到过滤的作用了 -->
    	             <filtering>false</filtering>
    	         </resource>
    	     </resources>
    	 </build>
    

    在这里插入图片描述

    • ④. 需求二:
      在xml中配置如下配置:
      在这里插入图片描述
        <build>
            <resources>
                <resource>
                    <directory>src/main/java</directory>
                    <includes>
                        <include>**/*.MF</include>
                        <include>**/*.XML</include>
                    </includes>
                    <filtering>true</filtering>
                </resource>
                <resource>
                    <!--资源文件的路径,默认位于${basedir}/src/main/resources/目录下-->
                    <directory>src/main/resources</directory>
                    <!--一组文件名的匹配模式,被匹配的资源文件将被构建过程处理-->
                    <includes>
                        <include>**/*</include>
                        <include>*</include>
                    </includes>
                    <!--filtering默认false,true表示通过参数对资源文件中的${key}
                    在编译时进行动态变更。替换源可紧-Dkey和pom中的<properties>值
                    或<filters>中指定的properties文件-->
                    <filtering>true</filtering>
                </resource>
            </resources>
        </build>
    

    ④. Maven默认属性

    	${basedir} 项目根目录  
    	${version}表示项目版本;  
    	${project.basedir}同${basedir};  
    	${project.version}表示项目版本,与${version}相同;  
    	${project.build.directory} 构建目录,缺省为target  
    	${project.build.sourceEncoding}表示主源码的编码格式;  
    	${project.build.sourceDirectory}表示主源码路径;  
    	${project.build.finalName}表示输出文件名称;  
    	${project.build.outputDirectory} 构建过程输出目录,缺省为target/classes 
    
        输出结果为:
    	test=${pro.name}
    	# F:\\mavenTest\\A 项目根目录
    	basedir=${basedir}
    	basedir2=${project.basedir}
    	# version=1.0-SNAPSHOT
    	version=${version}
    	# project.build.directory=F:\\mavenTest\\A\\target 构建目录,缺省为target
    	project.build.directory=${project.build.directory}
    	# project.build.sourceDirectory=F:\\mavenTest\\A\\src\\main\\java
    	# 表示主源码的编码格式
    	project.build.sourceDirectory=${project.build.sourceDirectory}
    	# project.build.finalName=A-1.0-SNAPSHOT 表示输出文件名称
    	project.build.finalName=${project.build.finalName}
    	# project.build.outputDirectory=F:\\mavenTest\\A\\target\\classes
    	# 构建过程输出目录,缺省为target/classes
    	project.build.outputDirectory=${project.build.outputDirectory}
    

    ③. Maven项目依赖、依赖冲突

    ①. 什么是依赖传递

    • ①.在maven中,依赖是可以传递的,假设存在三个项目,分别是项目A,项目B以及项目C。假设C依赖B,B依赖A,那么我们可以根据maven项目依赖的特征不难推出项目C也依赖A

    在这里插入图片描述

    • ②.通过上面的图可以看到,我们的web项目直接依赖了spring-webmvc,而spring-webmvc依赖了sping-aop、spring-beans等。最终的结果就是在我们的web项目中间接依赖了spring-aop、spring-beans等
      在这里插入图片描述

    ②. 什么是依赖冲突

    • ①. 加入如下坐标
      由于spring-webmvc中依赖了spring-core,而spring-core中依赖了commons-logging(1.1.3),而我们又引入了commons-loging1.2,就造成了冲突

    在这里插入图片描述

    • ②. 根据​路径近者优先原则,我们项目中引入的commons-logging为1.2

    在这里插入图片描述

    ④. 如何解决依赖冲突

    ①. 使用maven提供的依赖调解原则

    • ①. 依赖调节原则 — 第一声明者优先原则(在 pom 文件中定义依赖,以先声明的依赖为准。其实就是根据坐标导入的顺序来确定最终使用哪个传递过来的依赖)
      结论:通过上图可以看到,spring-aop和spring-webmvc都传递过来了spring-beans,但是因为spring-aop在前面,所以最终使用的spring-beans是由spring-aop传递过来的,而spring-webmvc传递过来的spring-beans则被忽略了
      在这里插入图片描述

    • ②. 根据​路径近者优先原则, 我们项目中引入的commons-logging为1.2
      在这里插入图片描述

    • ③. 如果在同一个pom中引入了两个相同的jar包,以引入的最后一个为准
      如下的配置引入的是1.2

        <dependencies>
            <dependency>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
                <version>1.1.2</version>
            </dependency>
            <dependency>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
                <version>1.2</version>
            </dependency>
        </dependencies>
    

    ②. 可选依赖optional

    • ①. 新建项目A(类似于mysql)、B(类似于oracle),项目C(类似于业务层,引入A、B工程),项目D(类似于逻辑工程,引入了C)
      C项目pom.xml如下:
    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        <parent>
            <artifactId>mavenTest</artifactId>
            <groupId>com.xiaozhi</groupId>
            <version>1.0-SNAPSHOT</version>
        </parent>
        <modelVersion>4.0.0</modelVersion>
    
        <artifactId>C</artifactId>
    
        <dependencies>
            <dependency>
                <groupId>com.xiaozhi</groupId>
                <artifactId>A</artifactId>
                <version>1.0-SNAPSHOT</version>
                <!-- optional=true,依赖不会传递,该项目依赖A
                    之后依赖该项目的项目如果想要使用A,需要重新引入 -->
                <optional>true</optional>
            </dependency>
            <dependency>
                <groupId>com.xiaozhi</groupId>
                <artifactId>B</artifactId>
                <version>1.0-SNAPSHOT</version>
                <optional>true</optional>
            </dependency>
        </dependencies>
    </project>
    

    在这里插入图片描述

    • ②. 画个图说明问题:
    1. 由于projectC使用到了两个来自projectA的类(OptionalFeatureAClass)和projectB的类(OptionalFeatureBClass).如果projectC没有依赖packageA和packageB,那么编译将会失败。
    2. projectD依赖projectC,但是对于projectD来说,类(OptionalFeatureAClass)和类(OptionalFeatureBClass)是可选的特性,所以为了让最终的war/ejbpackage不包含不必要的依赖,使用optional声明当前依赖是可选的,默认情况下也不会被其他项目继承(好比Java中的final类,不能被其他类继承一样)
      在这里插入图片描述
    • ③. 如果projectD确实需要用到projectC中的OptionalFeatureAClass怎么办呢?
      那我们就需要在projectD的pom.xml中显式的添加声明projectA依赖,继续看下图ProjectD需要用到ProjectA的OptionalFeatureAClass,那么需要在ProjectD的pom.xml文件中显式的添加对ProjectA的依赖

    在这里插入图片描述

    • ④. 到这也就很好理解为什么Maven为什么要设计optional关键字了,假设一个关于数据库持久化的项目(ProjectC),为了适配更多类型的数据库持久化设计,比如Mysql持久化设计(ProjectA)和Oracle持久化设计(ProjectB),当我们的项目(ProjectD)要用的ProjectC的持久化设计,不可能既引入mysql驱动又引入oracle驱动吧,所以我们要显式的指定一个,就是这个道理了

    ③. 排除依赖

    • 可以使用exclusions标签将传递过来的依赖排除出去

    在这里插入图片描述

    ④. 版本锁定[ 掌握 ]

    • ①. 采用直接锁定版本的方法确定依赖jar包的版本,版本锁定后则不考虑依赖的声明顺序或依赖的
      路径,以锁定的版本为准添加到工程中,此方法在企业开发中经常使用

    • ②. 版本锁定的使用方式:

    1. 在dependencyManagement标签中锁定依赖的版本
      在这里插入图片描述
    2. 在dependencies标签中声明需要导入的maven坐标
      在这里插入图片描述

    ④. 分模块构建maven工程

    ①. 分模块构建maven工程分析

    • ①. 不管是下面那种拆分方式,通常都会提供一个父工程,将一些公共的代码和配置提取到父工程中进行统一管理和配置
    1. 按照业务模块进行拆分,每个模块拆分成一个maven工程,例如将一个项目分为用户模块、订单模块、购物车模块等,每个模块都对应一个maven工程
    2. 按照层进行拆分,例如持久层、业务层、表现层等,每个层对应就是一个maven工程
    • ②. 图解
      在这里插入图片描述

    ②. maven工程的继承

    • ①. 在Java语言中,类之间是可以继承的,通过继承,子类就可以引用父类中非private的属性和方法。同样,在maven工程之间也可以继承,子工程继承父工程后,就可以使用在父工程中引入的依赖。继承的目的是为了消除重复代码

    • ②. 被继承的maven工程通常被称为父工程,父工程的打包方式必须为pom,所以我们区分某个maven工程是否为父工程就要看这个工程的打包方式是否为pom

    • ③. 继承其他maven父工程的通常称为子工程,在pom.xml文件中通过parent标签进行父工程的继承

    在这里插入图片描述

    ③. maven工程的聚合

    • ①. 在maven工程的pom.xml文件中可以使用<modules>标签将其他maven工程聚合到一起,聚合的目的是为了进行统一操作

    • ②. 例如拆分后的maven工程有多个,如果要进行打包,就需要针对每个工程分别执行打包命令,操作起来非常繁琐。这时就可以使用modules标签将这些工程统一聚合到maven工程中,需要打包的时候,只需要在此工程中执行一次打包命令,其下被聚合的工程就都会被打包了
      在这里插入图片描述

    展开全文
  • 详述 Maven 依赖范围及依赖调节原则

    千次阅读 2017-09-23 17:49:44
    当在我们 POM 文件中配置 Maven 依赖的时候,常见的格式如下: ... <groupId>... <artifactId>... <version>...</versio
  • Maven 依赖范围及依赖原则

    千次阅读 2018-04-14 01:03:36
    1.依赖范围 想必大家在maven的pom.xml文件中 定义依赖 除了 groupId ,artifactId,version三个必要的标签外,还见过 另外一个标签scope(如下)。没错这个标签就是我下面要说的依赖范围。 &amp;lt;...
  • maven依赖范围之import

    千次阅读 2019-12-29 17:08:21
    maven依赖范围之import import依赖范围。该依赖范围不会test、compile、runtime的 classpath 产生实际的影响。它的作用是将其他模块定义好的 dependencyManagement 导入当前 Maven 项目 pom 的 dependencyManagement...
  • Maven的依赖范围在pom.xml文件中,有个元素是scope,用来表示依赖的范围。之所以会有依赖范围,是因为Maven在编译、测试和运行项目时会各自使用一套classpath,依赖范围就是用来控制这三种classpath的。简单来说,...
  • 在Maven中依赖的域有这几个:import、provided、runtime、compile、system、test 1compile 的范围依赖的scope为compile的时候,那么当前这个依赖的包,会在编译的时候将这个依赖加入进来,并且在打包(mvn ...
  • Maven 依赖范围及依赖传递

    千次阅读 2018-01-18 23:20:32
    1. 依赖范围 scope 共 5 种依赖范围 , compile (编译) , test (测试) , runtime (运行时) , provided , system 不指定 , 则依赖范围默认为 compile compile : (编译依赖范围) , 在编译 , 测试 , 运行/打包时都会...
  • maven的依赖范围、依赖传递、依赖冲突、聚合和继承 目录 MAVEN maven的依赖范围、依赖传递、依赖冲突、聚合和继承 知识点 maven依赖范围 maven传递依赖 maven依赖冲突 Maven继承:父模块的pom文件修改 ...
  • 【maven】依赖范围

    热门讨论 2018-02-24 12:07:08
    在maven的pom.xml文件中进行了一系列的依赖配置,根元素project下的dependencies可以包含一个或者dependency元素,以...每个依赖可以包含的元素中其中有一个scope,声明依赖范围,我们来具体的了解一下依赖范围
  • 依赖范围就是用来控制依赖和三种classpath(编译classpath,测试classpath、运行classpath)的关系,Maven有如下几种依赖范围: compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven...
  • maven的几种依赖范围

    千次阅读 2018-07-03 14:35:26
  • Maven的6种依赖范围

    千次阅读 2017-09-23 09:45:24
    Maven的6种依赖范围: compile: 编译依赖范围(默认),对于编译、测试、运行三种classpath都有效 test: 测试依赖范围, 只对测试classpath有效。典型范例:Junit provided: 已提供依赖范围 对于编译和测试...
  • maven 依赖范围与classpath的关系

    千次阅读 2020-02-10 00:32:19
    依赖范围与classpath的关系 依赖范围 对于编译classpath有效 对于编译classpath有效 对于编译classpath有效 例子 compile Y Y Y spring-core test N Y N JUnit provided...
  • Maven依赖范围与classpath、依赖传递

    千次阅读 2018-11-01 20:44:06
    配置Junit依赖时,我们这样配置: &lt;dependency&gt; &lt;groupId&gt;junit&lt;/groupId&gt; &lt;artifactId&gt;junit&lt;/artifactId&gt; &lt;version&gt;...
  • maven中依赖范围简单解释

    千次阅读 2017-05-16 11:50:21
    首先需要知道,maven在编译项目主代码的时候需要使用一套classpath, 其次,maven在编译和...依赖范围就是用来控制依赖这三种classpath的关系,maven有以下集中依赖范围: 1):compile 编译以来范围,如果没有制
  • -- scope就是依赖范围的配置,如果不配置,默认的依赖范围是compile,现在看不懂没关系,等下会讲解。 --> < scope > provided scope > dependency > dependencies > 整体配置: < project ...
  • Maven 依赖范围和依赖传递详解

    千次阅读 2018-11-08 18:38:36
    Maven 依赖范围和依赖传递详解 18.10.8 松江图书馆 Maven 依赖范围和依赖传递详解 依赖基本配置 依赖范围 依赖传递 maven默认依赖体制 第一原则:以短路径长度为准 第二原则:相同路径长度时...
  • Maven依赖配置和依赖范围

    千次阅读 2017-03-06 17:27:32
    Maven依赖配置一个dependency的声明可以包含以下元素: <groupId>org.apache.kafka <artifactId>kafka-clients <version>0.8.2.2 <s
  • scope标签就是依赖范围!!! 在依赖声明中,scope标签指定的就是当前项目在什么情况下对目标项目有依赖。可选值包括:compile、test、provided、runtime、system: compile:默认值,适用于所有阶段(开发、...
  • maven 依赖范围影响传递性依赖

    千次阅读 2020-02-10 00:39:46
    compile test provided runtime compile ...备注:最左边一列表示第一直接依赖范围 最上面一行表示第二直接依赖范围 中间交叉的单元格表示传递性依赖范围  
  • Maven依赖范围及传递

    万次阅读 2014-08-08 16:13:24
    1、Maven因为执行一系列编译、测试和部署运行等操作,在不同的操作下使用的classpath不同,依赖范围就是用来控制依赖与三种 classpath(编译classpath、测试classpath、运行classpath)的关系。 Maven有以下几种...
  • 设置依赖范围 参考视频 13-依赖管理-依赖范围 1.设置依赖范围 可以对引入的资源进行设置,设置其生效的范围。生效范围主要有以下: 主代码是否有效 测试代码是否有效 是否参与打包 而上述三种不同范围的组合,便有...
  • Maven中使用scope来指定当前包的依赖范围和依赖的传递性。常见的可选值有:compile,provided,runtime,test,system等。scope主要是用在pom.xml文件中的依赖定义部分 <dependency> <groupId>mysql</...
  • 说maven依赖冲突之前需要先说说maven的 依赖传递。 依赖传递 当前项目引入了一个依赖,该依赖的依赖也会被引入项目。...这还得说说maven的 依赖范围依赖范围 maven引入依赖,并不是把jar包拷贝到项目中来...
  • 然后来学习一下依赖中的范围。 1.Maven默认创建web工程效果 打开Eclipse,我们来创建一个maven工程,其实maven创建java工程和web工程在界面上就一个简单区别。 在packaging这里选择有三项,如果选择jar,创建...
  • maven 命令和jar包依赖范围

    千次阅读 2018-01-31 16:33:44
    **依赖管理:对jar包管理过程 **项目构建:项目在编码完成后,对项目进行编译、测试、打包、部署等一系列的操作都通过命令来实现 2、maven项目的生命周期 在maven中存在“三套”生命周期,每一套生命周期相互...
  • Maven依赖规则和依赖范围

    千次阅读 2017-04-11 00:05:46
    maven传递依赖的版本确定规则,也就是对重复的间接依赖的包的选择规则:  1. 在工程的依赖树上,深度越浅,越被优先选择。如本例中的spring-jms. 由于pom中直接声明了3.0.2版本的spring-jms,所以3.0.2版本的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 606,911
精华内容 242,764
关键字:

依赖范围