maven中的dependency标签参数
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<type></type>
<optional></optional>
<scope></scope>
<classifier></classifier>
<systemPath></systemPath>
<exclusions></exclusions>
</dependency>groupId:项目的唯一标识(包结构)
artifactId:项目模块的唯一标识(项目名)
version:项目版本(遵循语义化版本规范)
type:指定依赖的文件类型,默认是
jarjar:表示该依赖项是一个 Java ARchive 文件,通常是一个编译好的
.jar包war:表示该依赖项是一个 Web ARchive 文件,一个
.war文件是一个包含了Web应用资源(如JSP文件、HTML文件、Servlet类等)的压缩文件,当项目依赖于某个Web应用的包或者该依赖本身就是一个Web应用时,使用war类型pom:表示该依赖项是一个 pom文件,pom文件通常用于管理项目的依赖版本、插件、构建等配置。在依赖管理(
dependencyManagement)中通常使用pom类型理解:当项目中需要引入很多依赖的时候,pom.xml文件会变得非常大,此时,我们就可以将公共的依赖项放在父项目的pom.xml中,这样父项目就只需要打包成一个pom文件,所有的子项目只要引入了父项目,就会下载父项目中定义的所有jar包了
ear:表示依赖项是一个 Enterprise ARchive 文件,
.ear文件通常用于 Java EE 应用服务器,它包含了应用程序的多个模块,如 EJB(Enterprise Java Beans)、JSP、Servlet 等,当你的项目依赖一个企业级应用(如 Java EE)时,可能会使用ear类型test-jar: 表示该依赖项是一个包含测试类的 JAR 文件,如果你的项目需要依赖另一个项目的测试代码(如集成测试),你可以使用
test-jar类型javadoc:表示该依赖项是一个 Javadoc 文件,Javadoc 是用来描述 Java API 文档的文件,如果需要将 API 文档作为依赖引入到项目中(通常在开发环境中使用),可以使用
javadoc类型
optional:表示该依赖在下游是否可选,默认是
false(必须引入),标记为true时表示该依赖项对于你的项目不是必需的场景举例:当前项目是B,B引入了C,如果引入C时指定的optional是true时,当A引入B时,C不会传递到A中
optional设置成true的好处
- 优化传递性依赖:有些依赖只是为了特定场景或者开发过程中使用(例如测试工具、日志框架等),它们并不需要被传递给依赖该项目的其他模块。在这种情况下,可以将这些依赖标记为可选的,减少传递给下游项目的依赖数量
- 避免不必要的依赖冲突:有时候,不同的模块或项目可能有不同版本的相同依赖,如果这些依赖只是针对某些特定功能或者开发场景时使用,我们可以通过
optional=true来避免不必要的冲突
scope:定义该依赖项在哪些阶段有效,默认是
compilecompile:表示该依赖项在
编译、测试、运行时都可用provided:表示该依赖项在
编译、测试时可用,但是在运行时由外部容器提供,如Servlet API就可由Tomcat提供xml<!-- 例子 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency>runtime:表示该依赖项
在编译时不可用,但是在运行时需要,通常是运行时库,比如数据库驱动、某些日志框架等,它们在编译的时候不需要,运行时需要加载xml<!-- 例子 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.26</version> <scope>runtime</scope> </dependency>test:表示该依赖项
仅在测试阶段可用,不会影响正常的编译或运行,通常用于单元测试框架、Mock框架等xml<!-- 例子 --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.1</version> <scope>test</scope> </dependency>system:表示该依赖是从本地文件系统中加载的,而不是通过 Maven 仓库下载的,你需要提供依赖的路径
xml<!-- 例子 --> <dependency> <groupId>com.example</groupId> <artifactId>local-library</artifactId> <version>1.0.0</version> <scope>system</scope> <systemPath>${project.basedir}/lib/local-library.jar</systemPath> </dependency>import(仅适用于 BOM):用于引入BOM(Bill of Materials),集中管理依赖版本
xml<!-- 例子 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
classifier:classifier元素用来帮助定义构件输出的一些附属构件。附属构件与主构件对应,比如主构件是 kimi-app-2.0.0.jar 该项目可能还会通过使用一些插件生成 如 kimi-app-2.0.0-javadoc.jar 、 kimi-app-2.0.0-sources.jar 这样两个附属构件。这时候,javadoc,sources就是这两个附属构件的classifier,这样附属构件也就拥有了自己唯一的坐标
场景举例:引用下面 shiro-web-2.0.0-jakarta.jar 就可以通过classifier属性指定
xml<dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-web</artifactId> <version>2.0.0</version> <classifier>jakarta</classifier> </dependency>注意:附属构件不是项目直接生成的,而是需要添加额外的插件
xml<!-- 需要在 build 标签下添加 maven-jar-plugin 插件,并为其配置 classifier 属性。例如,如果我们想要创建一个包含源代码的 artifact 变种,可以这样做--> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.2.0</version> <executions> <execution> <goals> <goal>jar</goal> </goals> </execution> <execution> <id>attach-sources</id> <goals> <goal>jar</goal> </goals> <configuration> <classifier>sources</classifier> </configuration> </execution> </executions> </plugin> </plugins> </build>
systemPath:该属性允许你引入不在 Maven 仓库中的依赖项,而是直接指定一个本地文件系统上的路径
- xml
<!-- 下面的${project.basedir} 是 Maven 项目的根目录 --> <dependency> <groupId>com.example</groupId> <artifactId>my-library</artifactId> <version>1.0.0</version> <scope>system</scope> <systemPath>${project.basedir}/lib/my-library.jar</systemPath> </dependency> 注意
- 当使用
systemPath时,scope必须设置为system - 不推荐用于生产环境:虽然
systemPath很方便,但它并不符合 Maven 的标准依赖管理机制,因为它依赖于本地路径。这意味着该依赖不会上传到远程仓库并且不同开发者的本地环境中可能存在不同的文件路径,导致构建不一致,因此systemPath仅应作为一种临时解决方案,或者在没有发布到 Maven 仓库的情况下使用 - 不支持依赖传递:使用
systemPath引入的 JAR 文件不会参与 Maven 的依赖传递机制。例如,假如你的项目依赖的库也有依赖项,Maven 不会自动下载这些依赖,只会下载你直接在systemPath中指定的文件。
- 当使用
exclusions:用于排除某个依赖项的 传递依赖,例如:当一个项目A依赖项目B,而项目B同时依赖项目C,如果项目A中因为各种原因不想引用项目C,在配置项目B的依赖时,可以排除对C的依赖
xml<project> ... <dependencies> <dependency> <groupId>sample.ProjectB</groupId> <artifactId>Project-B</artifactId> <version>1.0</version> <scope>compile</scope> <exclusions> <exclusion> <!-- declare the exclusion here --> <groupId>sample.ProjectC</groupId> <artifactId>Project-C</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project>- 注意
- 必须同时指定
groupId和artifactId - 不能使用通配符:Maven 不支持
*这样的通配符,也就是说,你不能一次性排除某个groupId下的所有依赖项,必须一个一个明确列出
- 必须同时指定
- 注意
参考链接