Maven 依赖范围(Dependency Scope)

Dependency Scope

Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.

依赖范围用于限制依赖项的传递性,也影响用于各种构建任务的类路径。

There are 6 scopes available:

compile

This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.

默认的 scope。编译依赖项可在项目的所有类路径中使用。此外,这些依赖关系被传播到依赖项目。

provided

This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

provided scope 很像 compile scope,但表示您希望JDK或容器在运行时提供依赖性。例如,当为Java企业版构建Web应用程序时,您会将servlet API和相关的JavaEE API的依赖项设置为提供的作用域,因为Web容器提供了这些类。此范围仅在编译和测试类路径上可用,并且不是传递性的。

runtime

This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.

此范围指示编译不需要依赖项,而是用于执行。它在运行时和测试类中,而不是编译类路径。

test

This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive.

此范围指示应用程序的正常使用不需要依赖项,并且仅可用于测试编译和执行阶段。这个范围不是传递的。

system

This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.

此范围与 provided 类似,只是必须显式地提供包含它的jar。工件总是可用的,而不是在存储库中查找的。

import

This scope is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency to be replaced with the effective list of dependencies in the specified POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

此范围仅支持在“依赖关系管理>节”中的类型POM的依赖项中。它指示要在指定的POM的<dependencyManagement>部分中用有效的依赖项列表替换的依赖项。由于它们被替换,具有导入范围的依赖项实际上并不参与限制依赖项的传递性。

备注

Each of the scopes (except for import) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, transitive dependencies of that dependency with the scope across the top row will result in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency will be omitted. 每个scope(除了导入)都会以不同的方式影响传递依赖关系,如下面的表所示。如果将依赖项设置为左列中的范围,则该依赖项与跨顶行的范围的传递依赖项将导致主项目中的依赖项与交叉点列出的范围。如果没有列出范围,则表示依赖项将被省略。

it is intended that this should be runtime scope instead, so that all compile dependencies must be explicitly listed - however, there is the case where the library you depend on extends a class from another library, forcing you to have available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive. 这应该是运行时范围,因此必须显式列出所有编译依赖项-但是,您所依赖的库从另一个库扩展了一个类,迫使您在编译时可用。由于这个原因,编译时依赖关系即使在传递时仍然保留为编译范围。

以上内容取自maven官网资料

案例

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.4</version>
            <scope>provided</scope>
        </dependency>

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

其他关于scope的资料

https://www.jianshu.com/p/a4fc54b5a6bf

https://blog.youkuaiyun.com/kimylrong/article/details/50353161

https://howtodoinjava.com/maven/maven-dependency-scopes/

https://www.baeldung.com/maven-dependency-scopes

https://www.tutorialspoint.com/maven/maven_manage_dependencies.htm

转载于:https://my.oschina.net/mengzhang6/blog/2877882

<think>嗯,用户想了解Maven依赖中的scope用法和相关场景。这个问题很具体,看来用户可能正在处理Java项目的依赖管理问题,需要明确不同scope的适用情况。从引用内容看,scopeMaven依赖管理的关键概念,决定了依赖在不同构建阶段的可用性。引用[1]和[2]都强调了scope对编译、测试、运行等生命周期阶段的影响。用户可能是中级开发者,因为初级开发者通常不会深究scope细节,而高级开发者可能更关注优化层面。需要系统性地解释scope的六种取值。引用[3][4][5]提供了重要补充信息,尤其是import和system这两种较少见的scope。要特别注意避免常见的理解误区,比如:-provided和runtime容易混淆-import不是真正的继承机制-system范围依赖的路径问题用户可能实际遇到了这些问题:依赖冲突、打包体积过大、测试环境异常等。在解释时要结合这些痛点,比如:-用provided避免ServletAPI冲突-用test优化生产包大小-用import管理多模块依赖还要注意技术细节的准确性:-compile是默认值,不声明scope时等效-runtime适用于数据库驱动等场景-system需要谨慎使用,可能破坏可移植性最后生成的提问要引导用户深入:传递性影响、版本冲突解决、现代替代方案等。这些延伸问题能帮助用户建立完整的依赖管理认知体系。</think>以下是Maven依赖中`<scope>`的详细说明及使用场景,结合引用内容整理: ### 一、Scope 核心作用 决定依赖在**构建生命周期不同阶段**的可用性,控制依赖的传递性,影响编译、测试、打包及运行行为[^2][^5]。 --- ### 二、六种 Scope 详解 #### 1. `compile`(**默认值**) - **作用阶段**:编译、测试、运行 - **传递性**:传递 - **场景**:核心依赖(如Spring Core、工具库)[^2][^5] ```xml <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>5.3.0</version> <!-- 默认 compile,可省略 --> </dependency> ``` #### 2. `provided` - **作用阶段**:编译、测试 - **传递性**:不传递 - **场景**:容器已提供的依赖(如Tomcat中的Servlet API)[^2][^5] ```xml <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> ``` #### 3. `runtime` - **作用阶段**:测试、运行 - **传递性**:传递 - **场景**:运行时必需但编译不需要(如JDBC驱动)[^2][^4] ```xml <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.25</version> <scope>runtime</scope> </dependency> ``` #### 4. `test` - **作用阶段**:测试 - **传递性**:不传递 - **场景**:单元测试依赖(如JUnit、Mockito)[^2][^5] ```xml <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> ``` #### 5. `system` - **作用阶段**:编译、测试 - **传递性**:不传递 - **场景**:使用本地系统路径的JAR(慎用,破坏可移植性)[^4] ```xml <dependency> <groupId>com.example</groupId> <artifactId>custom-lib</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>${project.basedir}/lib/custom-lib.jar</systemPath> </dependency> ``` #### 6. `import` - **作用阶段**:仅依赖管理 - **传递性**:不传递 - **场景**:继承多个父POM的依赖管理(替代`<parent>`)[^3][^5] ```xml <dependency> <groupId>com.example</groupId> <artifactId>base-parent</artifactId> <version>1.0</version> <type>pom</type> <scope>import</scope> </dependency> ``` --- ### 三、关键使用场景 | **问题类型** | **推荐 Scope** | **优势** | |---------------------|----------------|-----------------------------------| | 避免容器依赖冲突 | `provided` | 排除重复依赖,减小包体积[^5] | | 优化生产包体积 | `test` | 移除测试专用依赖[^5] | | 模块化依赖管理 | `import` | 实现多继承,集中管理依赖[^3][^5] | | 运行时动态加载依赖 | `runtime` | 解耦编译与运行环境[^4] | --- ### 四、最佳实践 1. **优先使用默认作用域**:非必要不指定scope,保持简单性 2. **谨慎使用system**:破坏项目可移植性,优先部署到仓库 3. **传递性控制**:通过`<optional>true</optional>`或调整scope阻断依赖传递[^5] 4. **多模块项目**:用`import`整合多个依赖管理POM[^3] > 示例:通过`import`整合依赖管理[^3] > ```xml > <!-- 父模块 pom.xml --> > <dependencyManagement> > <dependencies> > <dependency> > <groupId>com.example</groupId> > <artifactId>shared-deps</artifactId> > <version>1.0</version> > <type>pom</type> > <scope>import</scope> > </dependency> > </dependencies> > </dependencyManagement> > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值