Maven基础POM配置讲解

合集下载

【Maven】配置文件详解

【Maven】配置⽂件详解概述参考本⽂讲解Maven的配置⽂件及其命令的使⽤。

Maven及其项⽬⽬录结构Maven⽬录结构Maven⼯程⽬录结构其中pom指project object model (项⽬对象模型) 或者 package object management (依赖包对象管理器)配置⽂件Maven常⽤的核⼼配置⽂件包括全局配置⽂件settings.xml和项⽬配置⽂件pom.xml，还有不常⽤的⽤户配置⽂件settings.xmlnote 如果在上述三个配置⽂件中出现相同配置，则优先级如下：pom.xml>settings.xmlnote>settings.xml以下所有配置⽂件资源来源于课程《》，包含的资源列表如下：全局配置 settings.xml顶级标签settings.xml 配置包含如下顶级标签完整的settings.xml 配置<settings ...><localRepository/> <interactiveMode/> <usePluginRegistry/> <offline/> <pluginGroups/> <servers/> <mirrors/> <proxies/> <profiles/> <activeProfiles/> <activation/> <properties/> <repositories/> <pluginRepositories/> </settings><settings xmlns="/SETTINGS/1.0.0"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/SETTINGS/1.0.0https:///xsd/settings-1.0.0.xsd"><localRepository>${user.home}/.m2/repository</localRepository><interactiveMode>true</interactiveMode><usePluginRegistry>false</usePluginRegistry><offline>false</offline><pluginGroups><pluginGroup>org.apache.maven.plugins</pluginGroup></pluginGroups><servers><server><!--这是server 的id （注意不是⽤户登陆的id ）该id 与distributionManagement 中repository 元素的id 相匹配。

Mavenpom.xml详解

Mavenpom.xml详解⼀、pom 简介POM 是项⽬对象模型 (Project Object Model) 的简称, XML 格式,名称为 pom.xml ,它是 Maven 项⽬的核⼼配置⽂件,该⽂件⽤于管理源代码、配置⽂件、开发者的信息和⾓⾊、问题追踪系统、组织信息、项⽬授权、项⽬的url、项⽬的依赖关系等等.事实上,在 Maven 的世界中,⼀个项⽬可以什么都没有,甚⾄没有代码,但是必须包含 pom.xml ⽂件.并且⼀个 Maven 项⽬有且只有⼀个 pom.xml ⽂件,该⽂件必须在项⽬的根⽬录下.⼆、pom.xml 完整结构<project xmlns="/POM/4.0.0"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/POM/4.0.0/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>...</groupId><artifactId>...</artifactId><version>...</version><packaging>...</packaging><dependencies>...</dependencies><parent>...</parent><dependencyManagement>...</dependencyManagement><modules>...</modules><properties>...</properties><build>...</build><reporting>...</reporting><name>...</name><description>...</description><url>...</url><inceptionYear>...</inceptionYear><licenses>...</licenses><organization>...</organization><developers>...</developers><contributors>...</contributors><issueManagement>...</issueManagement><ciManagement>...</ciManagement><mailingLists>...</mailingLists><scm>...</scm><prerequisites>...</prerequisites><repositories>...</repositories><pluginRepositories>...</pluginRepositories><distributionManagement>...</distributionManagement><profiles>...</profiles></project>我们这⾥就选择⼀些⽐较常⽤的配置来说三、pom 常⽤配置1、坐标坐标是⼀个项⽬的唯⼀标识符,可以通过坐标准确的定位到某⼀个具体的项⽬.有了坐标进⾏定位之后,如果其它的 Maven 项⽬想使⽤该项⽬⽣成的 jar 包,只需要通过坐标引⼊依赖即可Maven 坐标是通过 groupId、artifactId、version 来共同定位的.groupId: 组织 Id ,表⽰当前模块所⾪属的项⽬.起名规范：⼀级域名(com、org).⼆级域名(公司名称).项⽬名称artifactId: 模块 Id, 表⽰⼀个项⽬中的某个模块,例如商城项⽬⾥⾯的订单模块、⽤户模块、商品模块...等等version：当前的版本为什么坐标需要三个元素才能定位呢?⽐如你⾃⼰的项⽬中需要使⽤某⼀个 jar 包,那么怎么找到这个 jar 包呢?这个时候你就需要使⽤ groupId 来定位这个 jar 包是属于哪个公司的哪个项⽬,定位到了项⽬之后呢,你还需要使⽤ artifactId 定位到该项⽬的具体模块,因为⼀个项⽬可以有很多的模块,定位到了具体模块之后呢,还需要使⽤ version 来定位具体的版本号,因为⼀个模块可以进⾏迭代,如果不指定具体的版本号也就⽆法准确的定位,这个类似于地理⾥⾯只有通过东经和北纬才能准确定位⼀个地理位置⼀样.<groupId>com.xiaomaomao.springAnalyse</groupId><artifactId>spring-ioc</artifactId><version>1.0-SNAPSHOT</version>2、全局变量 propertiesproperties: 全局属性,⼀般情况下⽤于定义全局的 jar 包版本.仅仅是定义全局变量,不起其他作⽤.应⽤场景:在实际项⽬中如果我们使⽤同⼀个公司的 jar 包, jar 包的版本号最好是保持⼀致,因为有时候 jar 包版本不⼀致的情况下,有可能会出现不同版本之间发⽣不兼容的错误, 我们这⾥就以 spring 为例,下⾯的这些依赖当中 spring-context、spring-webmvc 都是属于 spring 的 jar 包,并且它们的版本号都是 4.3.11.RELEASE,突然有⼀天,项⽬经理兴奋的告诉我,spring 推出了 5.0 版本,功能很强⼤,我们要升级版本,那么这个时候你就只能挨个的找到 spring 相关的依赖,⼀个⼀个的把它们升级到 5.0 版本,我们这⾥仅仅只有两个 spring 相关的依赖,改起来⽐较快,可是如果你的项⽬⾥⾯使⽤了⼏⼗个,甚⾄上百个 spring 的依赖呢?这个时候你挨个挨个的去替换,⼯作量⽐较⼤,并且还有可能⼀不留神改错了,好不容易改完了,也没有改错,终于可以休息⼀下了,这个时候项⽬经理那个糟⽼头⼦⼜来了,他告诉你 spring 5.0 有版本缺陷,我们还是改回原来的 4.3.11.RELEASE 版本吧,我想此时你是奔溃的,你就只能挨个挨个的将 spring 的依赖 jar 包⼀个⼀个的还原,好了,还原了,也改好了,终于没事了,你冷不丁的冒出⼀个念头,万⼀项⽬经理⼜要我切换成其它的版本,⼯作量太⼤了,有没有什么⽐较好的办法呢?答案是有的,我们就可以通过 properties 标签来统⼀管理 jar 包的版本<dependencies><dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>4.3.11.RELEASE</version></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-webmvc</artifactId><version>4.3.11.RELEASE</version></dependency><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.11</version><scope>test</scope></dependency><dependency><groupId>javax.servlet</groupId><artifactId>javax.servlet-api</artifactId><version>4.0.0</version><scope>provided</scope></dependency></dependencies>在 <properties> 标签中定义⼀类 jar 包的版本,引⼊依赖的时候通过 ${标签名} 的⽅式来控制版本<properties><spring-version>4.3.11.RELEASE</spring-version><junit-version>4.11</junit-version><javax.servlet-version>4.0.0</javax.servlet-version></properties><dependencies><dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>${spring-version}</version></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-webmvc</artifactId><version>${spring-version}</version></dependency><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>${junit-version}</version><scope>test</scope></dependency><dependency><groupId>javax.servlet</groupId><artifactId>javax.servlet-api</artifactId><version>${javax.servlet-version}</version><scope>provided</scope></dependency></dependencies>如果以后想统⼀切换 spring、junit 等 jar 包的版本,我们只需要在 properties 标签中切换就可以了,再也不⽤去依赖中挨个挨个的替换 jar 包的版本了3、dependencydependency 标签统⼀的定义在 dependencies 标签中,它代表的意思是我们可以通过该标签引⼊我们需要的相关 jar 包3.1、如何查找⼀个 jar 包的地址?Maven 依赖官⽹:3.1.1、进⼊官⽹,查找需要的 jar 包3.1.2、选择 jar 包版本3.1.3、复制依赖到项⽬ pom.xml 中3.2、如何查看引⼊的依赖4、依赖的 scope 作⽤域依赖的 scope 标签表⽰的意思是依赖的使⽤范围(也就是这个 jar 包在什么范围内是可以使⽤的),scope 的取值有 compile、test、provided、runtime、system 4.1、compile该依赖可以在整个项⽬中使⽤(是指代码范围, main ⽬录和 test ⽬录下都能使⽤这个依赖),参与打包部署.是 scope 的默认值.典型的例如: commons f ileupload 例如:我们修改 spring 核⼼依赖 spring-context 的 scope 为 test<dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>${spring-version}</version><scope>test</scope></dependency>在 main ⽬录下使⽤就出现了报错在 test ⽬录下使⽤就是正常的4.2、test该依赖只能在测试代码中使⽤(是指代码范围,只能在 test ⽬录下使⽤这个依赖),不参与打包部署.典型的例如: junit4.3、provided该依赖编写源代码时需要使⽤,因为当我们使⽤ Servlet 的时候,如果不添加 javax.servlet-api 依赖,就⽆法使⽤⾥⾯相关的 API,如果使⽤了编译就会报错,provided 不参与打包部署.只是在编写源码的时候使⽤,为什么不参与打包部署呢?因为我们的项⽬打包部署到服务器的时候,服务器会为我们提供 javax.servlet-api ,这⾥以 tomcat 为例,找到 tomcat 的安装⽬录,打开⾥⾯的 lib ⽬录,在 tomcat 容器启动的时候会为我们提供 servlet-api.jar ,那么我们项⽬中的 pom.xml 中就不需要再提供 servlet-api 这个依赖了4.4、runtime该依赖编写代码时不需要,运⾏时需要,参与打包部署.典型的例如数据库驱动 mysql-connector-java<dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>8.0.20</version></dependency>为什么编写代码时不需要呢？jvm 运⾏期的时候通过反射加载数据库驱动,完成例如注册驱动、获取连接、获取 PrepareStatement 对象等,我们编写代码的时候只是在编译期间,根本不会使⽤到数据库驱动,项⽬最终打包部署的时候也是需要数据驱动的,否则你⽆法连接数据库和操作 Sql 语句.4.5、system表⽰使⽤本地系统路径下的 jar 包,需要和 systemPath 配合使⽤,典型的例如 Oracle 数据库驱动: ojdbc.jar ,它是未授权 Maven 中央仓库的(刚刚去 Maven 中央仓库发现有,但是我们就假设它没有被Maven 中央仓库录⼊)有些 jar 包可能因为授权的问题或者是⼀些个⼈的 jar 包,这些 jar 包不会被 Maven 中央仓库录⼊,这个时候如果我们想在项⽬中使⽤这些 jar 包的话,我们可以先将 jar 包下载先来,然后可以在 pom.xml 中配置指向本地某个 jar 包的路径,引⼊相关的 jar 包对主程序是否有效对测试程序是否有效是否参与打包是否参与部署典型例⼦compile 是是是是spring-context test 否是否否junit provided 是是否否servlet-api 、jsp-api runtime 否否是是mysql-connector-java system -----引⼊ Oracle 驱动之后就可以使⽤了,没有出现报错其实吧,我觉得如果某些 jar 包 Maven 中央仓库没有录⼊,我们可以将需要的 jar 包下载下来,然后上传到私服中,通过左边从私服中下载就可以了.这⾥总结⼀下 scope 依赖范围4.6、远程仓库 repositoriesrepositories:⽤来配置当前⼯程使⽤的远程仓库依赖查找顺序:本地仓库--->当前⼯程 pom.xml 中配置的远程仓库--->⽤户级别的 settings.xml 中配置的远程仓库----> 全局 settings.xml 中配置的远程仓库---->Maven 中央仓库应⽤场景：如果有些 jar 包在 Maven 中央仓库没有,但是在其他仓库(例如:阿⾥仓库、spring 仓库、mybatis 仓库)⾥是有这个 jar 包的,例如 spring 新发布了⼀个版本,由于是刚发⾏的版本,性能不太稳定,这个时候Maven 中央仓库⼀般不会将这些 jar 包录⼊,但是你就是想⽤ spring 最新的版本,那么可以在 pom.xml 中通过配置 repositories 从指定的某公司官⽅仓库来获取相应的 jar 包<repositories><repository><id>spring_repo</id><name>Private Repository</name><url>http://repo.spring.io/milestone</url><layout>default</layout><releases><enabled>true</enabled><updatePolicy>always</updatePolicy><checksumPolicy>warn</checksumPolicy></releases><snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots></repository><repository><id>alimaven</id><name>aliyun maven</name><url>/nexus/content/groups/public/</url></repository></repositories>4.7、插件 plugins插件,就是⼀种⼯具.常见的如:清理插件 maven c lean p lugin ,编译插件 maven c ompile p lugin插件和依赖的区别:插件是⼯具,偏向于开发环境.和项⽬功能、源码、打包好的 jar 包没有任何关系.插件和依赖的关系,类似于 IDEA ⼯具和上线的 jar 包.Maven 的核⼼⽂件很⼩,主要的任务都是由插件来完成.定位到：%本地仓库%\org\apache\maven\plugins ,可以看到⼀些下载好的插件4.7.1、插件的⽬标 (Plugin Goals)⼀个插件通常可以完成多个任务,每⼀个任务就叫做插件的⼀个⽬标.如执⾏ mvn install 命令时,调⽤的插件和执⾏的插件⽬标如下4.7.2、将插件绑定到⽣命周期Maven 的⽣命周期是抽象的,实际需要插件来完成任务,这⼀过程是通过将插件的⽬标 (goal) 绑定到⽣命周期的具体阶段 (phase) 来完成的.例如将 maven-compiler-plugin 插件的 compile ⽬标绑定到 default ⽣命周期的 compile 阶段,完成项⽬的源代码编译.Maven 对⼀些⽣命周期的阶段（phase）默认绑定了插件⽬标,因为不同的项⽬有 jar、war、pom 等不同的打包⽅式,因此对应的有不同的绑定关系,其中针对 default ⽣命周期的 jar 包打包⽅式的绑定关系如下第⼆列中,冒号后⾯即是绑定的插件⽬标,冒号前⾯是插件的前缀(prefix),是配置和使⽤插件的⼀种简化⽅式.4.7.3、⾃定义绑定⽤户可以根据需要将任何插件⽬标绑定到任何⽣命周期的阶段, 例如将 maven-source-plugin 的 jar-no-fork ⽬标绑定到 default ⽣命周期的 package 阶段, 这样,以后在执⾏ mvn package 命令打包项⽬时,在 package 阶段之后会执⾏源代码打包,⽣成如 ehcache-core-2.5.0-sources.jar 形式的源码包.<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-source-plugin</artifactId><version>2.2.1</version><executions><execution><id>attach-source</id><phase>package</phase><goals><goal>jar-no-fork</goal></goals></execution></executions></plugin></plugins>……</build>4.7.4、pom.xml 中配置插件<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-clean-plugin</artifactId><version>3.0.0</version></plugin><plugin><groupId>org.apache.tomcat.maven</groupId><artifactId>tomcat7-maven-plugin</artifactId><version>2.2</version><configuration><path>/xiaomaomao</path><port>8888</port></configuration></plugin></plugins></build>这⾥有个很奇怪的现象,我使⽤ IDEA 帮我创建 Web 项⽬, IDEA ⾃动帮我下载了插件,其中 maven-clean-plugin 插件的版本是 3.1.0 ,我这⾥把插件的版本替换成了 3.0.0然后看⼀下我们加⼊的 maven-tomcat 插件五、超级 pom当我们利⽤ IDEA 为我们创建⼯程的时候,我们没有进⾏任何配置,为什么能下载各种插件呢?这是由于存在超级 pom 的原因,所有的 Maven 项⽬都要继承超级 pom,⾥⾯有 Maven 默认的⼀些配置超级 pom 存放位置: Maven 的安装⽬录\bin\maven-model-builder-3.6.0.jar\org\apache\maven\model\pom-4.0.0.xml解压开 maven-model-builder-3.6.0.jar 这个压缩包,⾥⾯有两个⽬录在 org/apache/maven/model/ ⽬录下有⼀个 pom-4.0.0.xml ,这个 pom 就是超级 pom ,例如⾥⾯就配置了相关的仓库信息。

maven项目结构说明

maven项目结构说明
Maven是一个基于Java平台的自动化构建工具，主要用于管理项目的构建、报告和文档。

它采用了一种基于项目对象模型（POM）的概念，使得开发者能够通过一个中央化的方式管理项目的构建和依赖关系。

一个标准的Maven项目结构通常包含以下几个部分：
1.根目录：这是项目的最外层目录，包含了项目的所有文件和文件夹。

2.src/main/：这个目录包含了项目的所有源代码和资源文件。

其中，src/main/java目录下存放Java源代码，src/main/resources 目录下存放其他资源文件，如Spring的xml配置文件和log4j的properties文件。

3.src/test/：这个目录包含了项目的测试代码，如基于JUnit 的测试代码。

4.target/：这个目录是编译后内容的放置文件夹，其中包含了编译后的class文件、测试报告、打包后的项目文件等。

5.pom.xml：这是Maven的基础配置文件，也是项目的核心配置文件。

它用于配置项目的各种信息，如项目的基本信息、依赖关系、插件管理等。

6..idea/：这是项目的配置文件夹，由IDE自动生成，不需要手动关注。

通过这种标准化的项目结构，Maven能够有效地管理项目的构建、依赖和打包等过程，提高了开发效率。

史上最全的maven的pom.xml文件详解（转载）

史上最全的maven的pom.xml⽂件详解（转载）此⽂出处：——1<project xmlns="/POM/4.0.0"2xmlns:xsi="/2001/XMLSchema-instance"3xsi:schemaLocation="/POM/4.0.0 /maven-v4_0_0.xsd ">45<!-- ⽗项⽬的坐标。

如果项⽬中没有规定某个元素的值，那么⽗项⽬中的对应值即为项⽬的默认值。

6坐标包括group ID，artifact ID和 version。

-->7<parent>89<artifactId>xxx</artifactId>101112<groupId>xxx</groupId>131415<version>xxx</version>1617<!-- ⽗项⽬的pom.xml⽂件的相对路径。

相对路径允许你选择⼀个不同的路径。

默认值是../pom.xml。

18 Maven⾸先在构建当前项⽬的地⽅寻找⽗项⽬的pom，其次在⽂件系统的这个位置（relativePath位置），19然后在本地仓库，最后在远程仓库寻找⽗项⽬的pom。

-->20<relativePath>xxx</relativePath>21</parent>2223<!-- 声明项⽬描述符遵循哪⼀个POM模型版本。

模型本⾝的版本很少改变，虽然如此，但它仍然是必不可少的，24这是为了当Maven引⼊了新的特性或者其他模型变更的时候，确保稳定性。

maven运行时的配置及命令详解

maven运⾏时的配置及命令详解上⾯是指定端⼝运⾏程序的，也可以先指定好，直接在上⾯的地⽅写jettty:run 当然，如果你是在控制台运⾏且安装了maven，直接可以进⼊项⽬的⽂件中：mvn jetty:run就是说，在控制台运⾏只要加上⼀个mvn就ok了源代码格式的包Maven install将项⽬输出构件部署到本地仓库maven最主要的作⽤有两个⽅⾯，⼀个是对jar包的依赖解决功能，⾃⼰管理jar包，另⼀个功能就是项⽬的构建，打包部署。

现在我觉得最重要的还是maven的⽣命周期和插件机制，下⾯就来总结⼀下吧。

mvn install 是将你打好的jar包安装到你的本地库中，⼀般没有设置过是在⽤户⽬录下的 .\下⾯。

mvn package 只是将你的代码打包到输出⽬录，⼀般的是 target下⾯。

eclipse插件，m2eclipse1.maven install相当于maven原⽣的命令： mvn install2.aven build是 m2eclipse这个插件⾃⼰创造的概念，需要你来配置到底需要执⾏什么命令，如下图中的goals输⼊的就是你想执⾏的命令： Goals就是mvn的意思，所以中间不需要加mvn了 Eclipse中maven常⽤的命令点击Run As就可以发现⼏个Maven的命令： Maven Build: 这个命令⽤于编译Maven⼯程，执⾏命令后会在target⽂件夹中的classes中⽣成对应的class⽂件。

Maven Clean: 删除target⽂件夹，即删除⽣成的package包以及class等⽂件。

Maven Test: 先⾃动进⾏编译，在运⾏所有的测试⽤例。

Maven install: 发布⽣成对应的package包。

注意：留意上⾯的命令的作⽤，build和test都会⽣成相应的class⽂件。

也就是说，当你新建⼀个maven⼯程，或者clean⼀个maven⼯程后，如果没有使⽤这两个命令，直接针对类进⾏测试，会跑出java.class.notfound的错误。

maven pom文件pluginrepositories标签详解

maven pom文件pluginrepositories
标签详解
在 Maven的`pom`文件中，`repositories`标签的作用是配置maven项目的远程仓库。

示例如下：
```xml
<repositories>
<repository>
<id>nexus</id>
<name>Nexus Repository</name>
<url>远程仓库地址</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled> </snapshots>
</repository>
</repositories>
```
按照上述配置，可以实现配置maven项目的远程仓库。

这样的配置在创建一个项目时，需要配置一次，比较麻烦。

在`pluginRepositories`标签中，可以配置 Maven从什么地方下载插件构件。

该元素的内部配置和`repository`完全一样，不再解释。

Maven基础-默认中央仓库[settings.xml配置详解]

Maven基础-默认中央仓库[settings.xml配置详解]Maven基础-默认中央仓库当我们创建⼀个简单的Maven项⽬后(只需要在pom.xml配置好依赖)，运⾏mvn clean install就可以把项⽬构建好，不需要我们⼿⼯下载任何jar，这全靠中央仓库的存在，它会⾃动从仓库下载。

这个仓库的定义是在${M2_HOME}/lib/maven-2.0.10-uber.jar ⾥⾯。

你可以在⾥⾯找到\org\apache\maven\project\pom-4.0.0.xml 这个⽂件，在这个⽂件⾥⾯定义了默认中央仓库的地址：<repositories><repository><id> central</id><name> Maven Repository Switchboard</name><layout> default</layout><url> /maven2</url><snapshots><enabled> false</enabled></snapshots></repository></repositories>如果你想覆盖中央仓库的默认地址，那么这⾥我们就会使⽤的镜像了，还在setting.xml⾥⾯配置：<settings>…<mirrors><mirror><id> maven-net-cn</id><name> Maven China Mirror</name><url> /content/groups/public/</url><mirrorOf> central</mirrorOf></mirror></mirrors>…</settings><mirrorOf>,表⽰只为central仓库做镜像，如果想为所有的仓库做镜像那么可以改为：<mirrorOf>*</mirrorOf>Maven配置详解maven2 ⽐起maven1 来说，需要配置的⽂件少多了，主要集中在pom.xml和settings.xml中。

maven pom 空参数

maven pom 空参数在Maven项目中，POM（Project Object Model）是一个XML文件，用于描述项目的配置信息和依赖关系。

当我们在POM文件中遇到空参数时，可能指的是以下几种情况：1. 空的<groupId>、<artifactId>、<version>参数，这些参数是必需的，用于唯一标识一个Maven项目。

如果这些参数为空，将导致构建失败。

通常，我们需要在POM文件中填写正确的参数值。

2. 空的<dependencies>参数，在<dependencies>标签中，我们定义项目所依赖的外部库。

如果这个参数为空，说明项目没有任何依赖，或者依赖已经在其他地方定义。

这种情况下，<dependencies>标签可以省略，或者保留空标签。

3. 空的<properties>参数，在<properties>标签中，我们可以定义一些属性，用于在POM文件中引用。

如果这个参数为空，说明项目没有定义任何属性。

这种情况下，<properties>标签可以省略，或者保留空标签。

4. 空的<build>参数，在<build>标签中，我们可以定义项目的构建配置，例如编译器版本、资源过滤、插件等。

如果这个参数为空，说明项目没有特殊的构建需求，可以使用Maven的默认配置。

这种情况下，<build>标签可以省略，或者保留空标签。

需要注意的是，空参数可能会导致构建失败或不符合预期的行为。

因此，在编写POM文件时，我们应该根据项目的实际需求，填写正确的参数值或者删除不需要的标签。

同时，我们还可以通过Maven插件和配置来进一步定制项目的构建过程。

Maven pom文件常用配置小结

Maven pom文件常用配置小结什么是POMProject Object Model，项目对象模型。

通过xml格式保存的pom.xml文件。

作用类似ant 的build.xml文件，功能更强大。

该文件用于管理：源代码、配置文件、开发者的信息和角色、问题追踪系统、组织信息、项目授权、项目的url、项目的依赖关系等等。

一个完整的pom.xml文件，放置在项目的根目录下。

<project xmlns="/POM/4.0.0"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/POM/4.0.0/maven-v4_0_0.xsd"><modelVersion>4.0.0</modelVersion><!– The Basics –><groupId>…</groupId><artifactId>…</artifactId><version>…</version><packaging>…</packagi ng><dependencies>…</dependencies><parent>…</parent><dependencyManagement>…</dependencyManagement><modules>…</modules><properties>…</properties><!– Build Settings –><build>…</build><reporting>…</reporting><!– More Project Information –><name>…</name><description>…</description><url>…</url><inceptionYear>…</inceptionYear><licenses>…</licenses><organization>…</organization><developers>…</developers><contributors>…</contributors><!– Environment Settings –><issueManagement>…</issueManagement><ciManagement>…</ciManagement><mailingLists>…</mailingLists><scm>…</scm><prerequisites>…</prerequisites><repositories>…</repositories><pluginRepositories>…</pluginRepositories><distributionManagemen t>…</distributionManagement><profiles>…</profiles></project>基本设置maven的协作相关属性<project xmlns="/POM/4.0.0"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/POM/4.0.0/maven-v4_0_0.xsd"><modelVersion>4.0.0</modelVersion><groupId>org.codehaus.mojo</groupId><artifactId>my-project</artifactId><version>1.0</version><packaging>war</packaging></project>1.groupId : 组织标识，例如：org.codehaus.mojo，在M2_REPO目录下，将是:org/codehaus/mojo目录。

java 中maven和pom文件的用法

java 中maven和pom文件的用法Java中Maven和POM文件的用法在Java开发过程中，Maven是一个常用的构建工具，而POM文件是Maven项目的核心配置文件。

本文将详细介绍Maven和POM文件的用法，并讲解如何使用它们来管理Java项目的构建和依赖。

1. Maven介绍Maven是一个基于项目对象模型（POM）的项目管理工具。

它提供了一种标准的方式来构建、测试和部署Java项目。

Maven还能够自动下载和管理项目所需的依赖库，使开发者能够更方便地管理项目的构建过程。

2. POM文件介绍POM文件是Maven项目的核心配置文件，它使用XML格式来描述项目的结构和构建配置。

POM文件定义了项目的坐标、依赖关系、插件配置等信息，Maven根据这些信息来进行构建和管理项目。

3. 创建Maven项目要使用Maven来构建Java项目，首先需要创建一个Maven项目。

可以使用使用IDE（如Eclipse、IntelliJ IDEA）自动生成Maven项目结构，或者手动创建包含POM文件的文件夹结构。

4. 配置POM文件POM文件包含在项目根目录下，并命名为pom.xml。

打开POM文件后，可以通过修改各种元素和属性来对项目进行配置。

a) 项目坐标POM文件的<groupId>、<artifactId>和<version>元素一起定义了项目的坐标。

groupId代表组织或者公司的唯一标识，artifactId代表项目的唯一标识，version代表项目的版本。

例如：<groupId>com.example</groupId><artifactId>my-project</artifactId><version>1.0</version>b) 依赖管理POM文件的<dependencies>元素用于管理项目的依赖关系。

maven配置多模块项目pommodules

maven配置多模块项⽬pommodules所有⽤Maven管理的真实的项⽬都应该是分模块的，每个模块都对应着⼀个pom.xml。

它们之间通过继承和聚合（也称作多模块，multi-module）相互关联。

那么，为什么要这么做呢？我们明明在开发⼀个项⽬，划分模块后，导⼊Eclipse变成了N个项⽬，这会带来复杂度，给开发带来不便。

为了解释原因，假设有这样⼀个项⽬，很常见的Web应⽤。

在这个应⽤中，我们分了⼏层：Dao层负责数据库交互，封装了Hibernate交互的类。

Service层处理业务逻辑，放⼀些Service接⼝和实现相关的Bean。

Web层负责与客户端交互，主要有⼀些Structs的Action类。

对应的，在⼀个项⽬中，我们会看到⼀些包名：org.myorg.app.daoorg.myorg.app.serviceorg.myorg.app.weborg.myorg.app.util这样整个项⽬的框架就清晰了，但随着项⽬的进⾏，你可能会遇到如下问题：1. 这个应⽤可能需要有⼀个前台和⼀个后台管理端（web或者swing），你发现⼤部分dao，⼀些service，和⼤部分util是在两个应⽤中可。

这样的问题，你⼀周内遇到了好⼏次。

2. pom.xml中的依赖列表越来越长以重⽤的，但是，由于⽬前只有⼀个项⽬（WAR），你不得不新建⼀个项⽬依赖这个WAR，这变得⾮常的恶⼼，因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，⽽且你根本不需要org.myorg.app.web。

有⼈修改了dao，提交到svn并且不⼩⼼导致build失败了，你在编写service的代码，发现编译不过，只能等那⼈把dao修复了，你才能继续进⾏，很多⼈都在修改，到后来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引⼊。

甚⾄出现了⼀个依赖有多个版本存在。

3. build整个项⽬的时间越来越长，尽管你只是⼀直在web层⼯作，但你不得不build整个项⽬。

idea中的pom文件解析

idea中的pom文件解析【原创实用版】目录1.介绍 idea 的 pom 文件2.pom 文件的结构和内容3.pom 文件的解析方法4.pom 文件解析的实际应用正文一、介绍 idea 的 pom 文件在 Maven 项目中，pom（project object model）文件是非常重要的一个组成部分。

它包含了项目的构建配置、依赖关系和插件等信息，对于项目的构建和管理起着至关重要的作用。

而在 idea 中，pom 文件则承担了同样的角色，为 idea 提供了项目的构建和管理信息。

二、pom 文件的结构和内容pom 文件的基本结构如下：```<project><modelVersion>版本号</modelVersion><groupId>组名</groupId><artifactId>项目名</artifactId><version>版本号</version><packaging>打包方式</packaging><name>项目名称</name><url>项目网址</url><description>项目描述</description><properties>属性设置</properties><dependencies>依赖关系</dependencies><build>构建配置</build><reporting>报告配置</reporting><plugins>插件配置</plugins></project>```每个节点都对应了 pom 文件中的一个部分，它们共同构成了 pom 文件的基本内容。

maven configuration解析

Maven是一个流行的项目管理工具，它主要用于Java评台的项目构建、依赖管理和项目报告的生成。

在Maven中，配置是一个非常重要的部分，它决定了项目的构建、打包、部署等行为。

本文将对Maven 的配置进行解析，包括Maven的配置文件、项目的POM文件以及常见的配置项。

一、Maven的配置文件Maven的配置文件包括全局配置文件和用户配置文件。

全局配置文件是指Maven安装目录下的conf目录中的settings.xml文件，它包含了Maven的全局配置信息，例如Maven的本地仓库路径、代理服务器设置、镜像设置等。

用户配置文件是指用户目录下的.m2目录中的settings.xml文件，它包含了用户自定义的配置信息，例如用户的身份认证信息、仓库的设置等。

二、项目的POM文件Maven项目的POM文件是项目的核心配置文件，它包含了项目的基本信息、依赖关系、构建配置等。

POM文件的主要配置包括：1. 项目的基本信息：包括项目的groupId、artifactId、版本号等，这些信息在Maven中用来唯一标识一个项目。

2. 项目的依赖关系：通过dependencies元素可以指定项目的依赖项，包括依赖的groupId、artifactId、版本号等信息。

3. 项目的构建配置：包括项目的源代码目录、资源目录、输出目录等，通过build元素可以指定项目的构建配置信息。

4. 项目的插件配置：Maven通过插件来完成各种构建任务，通过plugins元素可以指定项目所使用的插件及其配置信息。

三、常见的配置项除了全局配置文件和POM文件外，Maven还有一些常见的配置项，这些配置项可以通过命令行参数、环境变量、系统属性等方式进行配置，主要包括：1. 仓库的配置：Maven使用仓库来存储项目的依赖项，通过指定仓库的路径、远程仓库的位置区域等可以进行仓库的配置。

2. 编译插件的配置：Maven使用插件来完成项目的编译任务，通过配置插件的参数可以对编译过程进行定制。

POM中profile配置maven根据不同的运行环境，打包不同的配置文件

POM中profile配置maven根据不同的运⾏环境，打包不同的配置⽂件1.⾸先在pom添加如下profile配置<profiles><profile><id>dev</id><properties><profiles.active>dev</profiles.active></properties><activation><activeByDefault>true</activeByDefault></activation></profile><profile><id>test</id><properties><profiles.active>test</profiles.active></properties></profile><profile><id>pro</id><properties><profiles.active>pro</profiles.active></properties></profile></profiles>2.⼯程⽬录src/main/resources中建⽴对应配置如开发环境、测试环境、⽣产环境的配置⽂件分别放到src/main/resources⽬录下的dev、test、pro三个⼦⽬录中，剩余公共的配置⽂件放于resources⽬录下,如dev的config.properties：hibernate.dialect=org.hibernate.dialect.OracleDialecthibernate.connection.driver_class=oracle.jdbc.driver.OracleDriverername=platform_portal_servicehibernate.connection.password=kingstar#hibernate.connection.url=jdbc:oracle:thin:@127.0.01:1521:orclhibernate.connection.url=jdbc:oracle:thin:@127.0.01:1521/dev3.在pom中的build节点下，配置资源⽂件的位置，如下所⽰：<build><resources><resource><directory>src/main/resources</directory><excludes><exclude>test/*</exclude><exclude>pro/*</exclude><exclude>dev/*</exclude></excludes></resource><resource><directory>src/main/resources/${profiles.active}</directory></resource></resources></build>⾸先第⼀个资源⽂件位置src/main/resources需要排队提各个环境的配置⽂件，各个环境的配置我们在第⼆个节点中通过前⾯在profile中配置的profiles.active属性来指定。

java代码解析maven的pom

一、介绍Maven的POM文件Maven是一个用于项目管理和构建的工具，它使用项目对象模型（Project Object Model，POM）来描述项目的结构和依赖关系。

POM文件是Maven项目的核心，它包含了项目的基本信息、依赖关系、插件配置等重要内容。

在Maven中，POM文件以pom.xml的形式存在，它是Maven项目的重要配置文件。

二、POM文件的基本结构1. 项目基本信息POM文件中的基本信息包括项目的坐标（groupId、artifactId、version）、项目名称、描述等。

其中，groupId用于唯一标识项目的组织或者公司，artifactId用于唯一标识项目的名称，而version用于唯一标识项目的版本号。

2. 依赖管理POM文件中的<dependencies>标签用于管理项目的依赖关系，它可以指定项目所依赖的外部库或者模块。

在<dependencies>标签中，可以通过<dependency>子标签来指定具体的依赖项，包括依赖的坐标、版本范围等信息。

3. 构建配置POM文件中的<build>标签用于配置项目的构建过程，其中包括了插件配置、资源目录、输出目录等。

通过<plugins>子标签，可以指定项目所使用的各种构建插件，例如编译插件、测试插件、打包插件等。

4. 配置继承POM文件支持继承关系，通过<parent>标签可以指定项目的父级POM，从而实现配置的继承和复用。

5. 自定义配置除了上述基本结构外，POM文件还可以包含一些自定义的配置内容，例如自定义属性、插件配置、构建生命周期等。

三、常见的POM文件解析技巧1. 使用XSD验证POM文件的结构和语法是有一定的约束的，可以通过XML Schema Definition（XSD）来验证POM文件的正确性。

通过在IDE 或者文本编辑器中配置相应的XSD，可以及时发现和纠正POM文件中的错误。

关于maven中pom和settings的配置

Maven1.Maven主要功能：构建项目(Builds)文档编制(Documentation)报告(Reporting)依赖管理(Dependencies)配置管理(SCMs)发布管理(Releases)2.Maven基本命令创建Maven目录mvn archetype:create -DgroupId=com.yourCompanyName-DartifactId=yourAppName测试mvn test编译类mvn compile打包mvn package生成Sitemvn site清除mvn clean以上命令都是在command窗口运行的.它们还可以混合运行,如mvn test compile package3.Maven的生命周期及其与之对应的命令：validate:验证工程是否正确，所有需要的资源是否可用。

compile:编译项目的源代码。

test-compile:编译项目测试代码。

test:使用已编译的测试代码，测试已编译的源代码。

package:已发布的格式，如jar，将已编译的源代码打包。

integration-test:在集成测试可以运行的环境中处理和发布包。

verify:运行任何检查，验证包是否有效且达到质量标准。

install:把包安装在本地的repository中，可以被其他工程作为依赖来使用deploy:在整合或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。

generate-sources:产生应用需要的任何额外的源代码，如xdoclet。

、4.pom.xml的结构上面就是前次HelloMaven工程的pom.xml文件,我们可以通过修改其中的元素使工程按照我们的意图运行,对于接触Maven的人,主要就是和pom.xml文件在打交道.pom.xml文件基本节点介绍：<project>:文件的根节点.<modelversion>:pom.xml使用的对象模型版本.<groupId>:创建项目的组织或团体的唯一Id.<artifactId>:项目的唯一Id,可视为项目名.<packaging>:打包物的扩展名，一般有JAR,WAR,EAR等<version>:产品的版本号.<name>:项目的显示名，常用于Maven生成的文档。

Maven打包pom里面配置exclude排除掉环境相关的配置文件

Maven打包pom⾥⾯配置exclude排除掉环境相关的配置⽂件Maven打包pom⾥⾯配置exclude 排除掉环境相关的配置⽂件有⼏种⽅式：1. 打包时，指定环境参数把环境的配置⽂件复制过去2. 不打包所有的环境相关的配置⽂件，直接由运维的⼈维护可以在上传war包前把配置给改了，⽤rar⼯具改⾥⾯的配置，但每次都改太⿇烦第⼀次上⾯放有这个配置⽂件，后⾯打包时排除掉就可以了，上⾯的解压后就不会覆盖了我们公司就⽤2，后⾯打包时排除掉就可以了，上⾯的解压后就不会覆盖了Maven打包pom⾥⾯配置exclude 排除掉环境相关的配置⽂件， resources excludes关于Maven resource配制中include与exclude的关系<include>与<exclude>是⽤来圈定和排除某⼀⽂件⽬录下的⽂件是否是⼯程资源的。

如果<include>与<exclude>划定的范围存在冲突时，以<exclude>划定的范围为准。

⼤多数情况下，⼈们使⽤<include>和<exclude>是为了配合<filtering>实现过滤特定⽂件的需要。

例如，在⼀个⼯程中，src/main/resources⽬录下都是⼯程的资源⽂件，并不需要<include>和<exclude>再进⾏划定。

但如果我们需要对且仅对其中的jdbc.properties和mail.properties两个⽂件进⾏过滤的话，则需要借助<include>和<exclude>进⾏如下的配置：<resources><resource><directory>src/main/resources</directory><filtering>true</filtering><includes><include>jdbc.properties</include><include>mail.properties</include></includes></resource><resource><directory>src/main/resources</directory><filtering>false</filtering><excludes><exclude>jdbc.properties</exclude><exclude>mail.properties</exclude></excludes></resource></resources>其中第⼀段<resource>配置声明：在src/main/resources⽬录下，仅jdbc.properties和mail.properties两个⽂件是资源⽂件，然后，这两个⽂件需要被过滤。

Maven的pom.xml文件结构之基本配置parent和继承结构

Maven的pom.xml文件结构之基本配置parent和继承结构1.Maven项目的继承Maven项目之间不仅存在多模块的聚合关系，而且Maven项目之间还可以存在相互继承的关系。

Maven项目之间的继承关系通过<parent>表示，在子Maven项目的POM中配置示例如下：[html] view plain copy1.<parent>2.<groupId>com.ericsson.jcat</groupId>3.<artifactId>jcat-bundle</artifactId>4.<version>2.0</version>5.<relativePath>../jcat-bundle</relativePath>6.</parent>说明：给出被继承的父项目的具体信息。

其中的relativePath给出父项目相对于子项目的路径，这样在构件子项目时首先从该相对路径查找父项目，如果没有才会从本地库或进而远程库中查找父项目。

2.在子项目中，能够继承父项目的如下配置：•dependencies•developers•contributors•plugin lists•reports lists•plugin executions with matching ids•plugin configuration3.Maven的Super POM类似于Java中的ng.Object类，所有Java类都继承自该类。

在Maven中也存在一个特殊的POM，被称为Super POM。

任何Maven项目的POM都继承自Super POM。

在Super POM中，设置如下：•Maven的central库•Maven的central插件库•build的基本参数和4个插件（maven-antrun-plugin、maven-assembly-plugin、maven-dependency-plugin和maven-release-plugin）•reporting的基本目录•一个profile（id=release-profile）。

maven仓库配置pom中repositories属性

maven仓库配置pom中repositories属性什么是Maven仓库在不⽤Maven的时候，⽐如说以前我们⽤Ant构建项⽬，在项⽬⽬录下，往往会看到⼀个名为/lib的⼦⽬录，那⾥存放着各类第三⽅依赖jar⽂件，如log4j.jar，junit.jar等等。

每建⽴⼀个项⽬，你都需要建⽴这样的⼀个/lib⽬录，然后复制⼀对jar⽂件，这是很明显的重复。

重复永远是噩梦的起点，多个项⽬不共⽤相同的jar⽂件，不仅会造成磁盘资源的浪费，也使得版本的⼀致性管理变得困难。

此外，如果你使⽤版本管理⼯具，如SVN（你没有使⽤版本管理⼯具？马上试试SVN吧，它能帮你解决很多头疼的问题），你需要将⼤量的jar⽂件提交到代码库⾥，可是版本管理⼯具在处理⼆进制⽂件⽅⾯并不出⾊。

Maven仓库就是放置所有JAR⽂件（WAR，ZIP，POM等等）的地⽅，所有Maven项⽬可以从同⼀个Maven仓库中获取⾃⼰所需要的依赖JAR，这节省了磁盘资源。

此外，由于Maven仓库中所有的JAR都有其⾃⼰的坐标，该坐标告诉Maven它的组ID，构件ID，版本，打包⽅式等等，因此Maven项⽬可以⽅便的进⾏依赖版本管理。

你也不在需要提交JAR⽂件到SCM仓库中，你可以建⽴⼀个组织层次的Maven仓库，供所有成员使⽤。

简⾔之，Maven仓库能帮助我们管理构件（主要是JAR）。

本地仓库（.m2） vs. 远程仓库（联⽹）运⾏Maven的时候，Maven所需要的任何构件都是直接从本地仓库获取的。

如果本地仓库没有，它会⾸先尝试从远程仓库下载构件⾄本地仓库，然后再使⽤本地仓库的构件。

⽐如说，你的项⽬配置了junit-3.8的依赖，在你运⾏mvn test 的时候，Maven需要使⽤junit-3.8的jar⽂件，它⾸先根据坐标查找本地仓库，如果找到，就直接使⽤。

如果没有，Maven会检查可⽤的远程仓库配置，然后逐个尝试这些远程仓库去下载junit-3.8的jar⽂件，如果远程仓库存在该⽂件，Maven会将其下载到本地仓库中，继⽽使⽤。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

Maven依赖范围 <scope></scope>
三套classpath：编译classpath、测试classpath、运行classpath。依赖范围就是用来控制，依赖（dependency）与这三种classpath的关系。 Maven提供的依赖范围： compile：编译依赖范围（默认依赖范围）。全有效（spring-core） test：测试依赖范围。测试classpath有效（junit） provided：已提供依赖范围。编译和测试classpath有效（servlet-api） runtime：运行时依赖范围。测试和运行classpath有效（JDBC驱动） system：系统依赖范围。与provided一样（需要指定路径，非Maven仓库） import：导入依赖范围。不会对三种classpath产生实际的影响。依赖范围 compile test provided runtime system 编译有效 √ ― √ ― √ 测试有效 √ √ √ √ √ 运行有效 √ ― ― √ ― 例子 Spring-core Junit Servlet-api JDBC驱动
Maven模块概念
1、在Maven中，一个项目会被划分成很多模块。比如:org.SpringFramework项目，对应的Maven模块会有很多，如：spring-core、spring-context。
2、 groupId不应该只对应到公司（组织）的名称。因为一个公司（组织）会有很多的项目，当 artifactId 定义Maven模块，而groupId只定义到公司（组织）名称时，项目名称将难以定义。
第一原则：路径最近者优先第二原则：第一声明者优先
可选依赖（true）现有如下依赖：模块A依赖于模块B，模块B依赖于模块X和Y。
X（可选依赖） A B Y（可选依赖）
三个依赖的范围都是compile，但是X和Y都是可选依赖，所以依赖将不会得以传递。也就是说，X和Y不会对A有任何影响。说明：X和Y都支持数据库，在使用的时候需要两种驱动，但是使用的时候，只会依赖一种驱动，需要在A中显示的配置出来。
Maven学习-- 3.0
@author
Maven坐标详解
<groupId>org.sonatype.nexus</groupId> 定义当前Maven项目隶属的实际项目。 <artifactId>nexus-indexer</artifactId> 该元素定义实际项目中的一个Maven项目，推荐使用实际项目名称作为前缀。 <version>2.0.0</version> 该元素定义Maven项目当前所处的版本。 <packaging> jar</packaging> 该元素定义Maven项目的打包方式：.jar .war <classifier></classifier> 该元素用来帮助定义构建输出的一些附属构件说明：上述5个元素， groupId、 artifactId、 version是必须定义的， packaging是可选的（默认为 .jar）， classifier是不能直接定义的。
runtime runtime
compile
test
provided runtime
test
provided runtime
―
― ―
―
provided ―
test
provided runtime
依赖调节(两大原则) ABCX(1.0) ABX(2.0) ABX(1.0) ACX(2.0)
Maven排除依赖 <exclusions> </exclusions>
Maven的传递性依赖会隐式地传入很多依赖，但是会有一些问题。例如：A依赖于B，B依赖于很多（C、D、E、F）,但是我们不想引入C的依赖。这个时候，就需要使用排除依赖。如下： <exclusions> <exclusion> <groupId> </groupId> <artifactId> </artifactId> </exclusion> </ exclusions> 我们排除了C的依赖的同时，也可以显式的引compile依赖范围的spring-core依赖，spring-core有一个 compile依赖范围的commons-loggings依赖。则commons-loggings是本模块的传递性依赖。依赖范围影响传递性依赖
第二依赖第一依赖
compile compile
test ―
provided ―
Maven依赖解析
在开发时，Maven会自动的帮我们解析直接依赖和传递性依，并确保不会产生依赖冲突。在完成这些工作以后，得到的最后的依赖称为已解析依赖。命令： mvn dependency:list mvn dependency:tree mvn dependency:analyze(工具)
本地的 Maven仓库之外
Maven可选依赖 <optional></ optional>
传递性依赖（机制）：例如：项目需要spring-core.jar，spring-core.jar还需要别的.jar，那么两者都需要手动导入，这是很麻烦的。而Maven可以很好的解决这个问题。
本模块 Spring-core Commons-loggings
Maven依赖配置
一个依赖（<dependency>）的声明可以包含以下元素： <project> <dependencies> <dependency> <groupId> </groupId> <artifactId> </artifactId> 依赖的基本坐标，Maven根据坐标 <version> </version> 才能找到依赖。 <type></type> 依赖的类型，对应packaging，默认 .jar <scope></scope> 依赖的范围。 <optional></ optional> 是否为可选依赖。 <exclusions> 用来排除传递性依赖。 <exclusion> </exclusion> </ exclusions> </dependency> </dependencies> </project>
To be continued……