2023年8月1日发(作者：)
JAVA项⽬中是什么？有什么作⽤？转载⾃ 原创Alan_ckc
什么是POM？POM是项⽬对象模型(Project Object Model)的简称,它是Maven项⽬中的⽂件，使⽤XML表⽰，名称叫做。作⽤类似ant的⽂件，功能更强⼤。该⽂件⽤于管理：源代码、配置⽂件、开发者的信息和⾓⾊、问题追踪系统、组织信息、项⽬授权、项⽬的url、项⽬的依赖关系等等。事实上，在Maven世界中，project可以什么都没有，甚⾄没有代码，但是必须包含⽂件。概览下⾯是⼀个POM项⽬中的⽂件中包含的元素。注意，其中的modelVersion是4.0.0，这是当前仅有的可以被Maven2&3同时⽀持的POM版本，它是必须的。⼀，基本配置1.1 maven的协作相关属性 ⼀个最简单的的定义必须包含modelVersion、groupId、artifactId和version这四个元素，当然这其中的元素也是可以从它的⽗项⽬中继承的。在Maven中，使⽤groupId、artifactId和version组成groupdId:artifactId:version的形式来唯⼀确定⼀个项⽬：1.2 POM之间的关系，继承、聚合与依赖 我们知道Maven在建⽴项⽬的时候是基于Maven项⽬下的进⾏的，我们项⽬依赖的信息和⼀些基本信息都是在这个⽂件⾥⾯定义的。那如果当我们有多个项⽬要进⾏，这多个项⽬有些配置内容是相同的，有些是要彼此关联的，那如果按照传统的做法的话我们就需要在多个项⽬中都定义这些重复的内容。这⽆疑是⾮常耗费时间和不易维护的。好在Maven给我们提供了⼀个pom的继承和聚合的功能。 对于使⽤java的⼈⽽⾔，继承这个词⼤家应该都不陌⽣。要继承pom就需要有⼀个⽗pom，在Maven中定义了超级，任何没有申明⾃⼰⽗的都将默认继承⾃这个超级。 位置： 在Maven 版本中，⽐如，打开此Jar⽂件后，在包包t下会有的⽂件。 但是到了版本之后在： aven安装⽬录下的：/lib/中 orgapachemavenmode⽬录中的。 先来看⼀下这个超级的定义： 4.0.0 ${r}/target ${ory}/classes ${ctId}-${n} ${ory}/test-classes ${r}/src/main/java ${r}/src/main/scripts ${r}/src/test/java ${r}/src/main/resources ${r}/src/test/resources maven-antrun-plugin 1.3 maven-assembly-plugin 2.2-beta-5 maven-dependency-plugin 2.8 maven-release-plugin 2.3.2 ${ory}/site release-profile performRelease true true maven-source-plugin attach-sources jar true maven-javadoc-plugin attach-javadocs jar true maven-deploy-plugin true 对于⼀个来说有⼏个元素是必须定义的，⼀个是project根元素，然后就是它⾥⾯的modelVersion、groupId、artifactId和version。由上⾯的超级的内容我们可以看到中没有groupId、artifactId和version的定义，所以我们在建⽴⾃⼰的的时候就需要定义这三个元素。和java⾥⾯的继承类似，⼦会完全继承⽗中所有的元素，⽽且对于相同的元素，⼀般⼦中的会覆盖⽗中的元素，但是有⼏个特殊的元素它们会进⾏合并⽽不是覆盖。这些特殊的元素是：dependenciesdeveloperscontributorsplugin列表，包括plugin下⾯的reportsresources1.2.1 继承1.2.1.1 被继承项⽬与继承项⽬是⽗⼦⽬录关系 现在假设我们有⼀个项⽬projectA，它的定义如下： 然后我们有另⼀个项⽬projectB，⽽且projectB是跟projectA的⽂件处于同⼀个⽬录下，这时候如果projectB需要继承⾃projectA的话我们可以这样定义projectB的⽂件。 由projectB的⽂件的定义我们可以知道，当需要继承指定的⼀个Maven项⽬时，我们需要在⾃⼰的中定义⼀个parent元素，在这个元素中指明需要继承项⽬的groupId、artifactId和version。1.2.1.2 被继承项⽬与继承项⽬的⽬录结构不是⽗⼦关系 当被继承项⽬与继承项⽬的⽬录结构不是⽗⼦关系的时候，我们再利⽤上⾯的配置是不能实现Maven项⽬的继承关系的，这个时候我们就需要在⼦项⽬的⽂件定义中的parent元素下再加上⼀个relativePath元素的定义，⽤以描述⽗项⽬的⽂件相对于⼦项⽬的⽂件的位置。 假设我们现在还是有上⾯两个项⽬，projectA和projectB，projectB还是继承⾃projectA，但是现在projectB不在projectA的⼦⽬录中，⽽是与projectA处于同⼀⽬录中。这个时候projectA和projectB的⽬录结构如下： ------projectA ------ ------projectB ------ 这个时候我们可以看出projectA的相对于projectB的的位置是“../projectA/”，所以这个时候projectB的的定义应该如下所⽰：1.2.2 聚合 对于聚合这个概念搞java的⼈应该都不会陌⽣。先来说说我对聚合和被聚合的理解，⽐如说如果projectA聚合到projectB，那么我们就可以说projectA是projectB的⼦模块， projectB是被聚合项⽬，也可以类似于继承那样称为⽗项⽬。对于聚合⽽⾔，这个主体应该是被聚合的项⽬。所以，我们需要在被聚合的项⽬中定义它的⼦模块，⽽不是像继承那样在⼦项⽬中定义⽗项⽬。具体做法是：修改被聚合项⽬的中的packaging元素的值为pom在被聚合项⽬的中的modules元素下指定它的⼦模块项⽬对于聚合⽽⾔，当我们在被聚合的项⽬上使⽤Maven命令时，实际上这些命令都会在它的⼦模块项⽬上使⽤。这就是Maven中聚合的⼀个⾮常重要的作⽤。假设这样⼀种情况，你同时需要打包或者编译projectA、projectB、projectC和projectD，按照正常的逻辑我们⼀个⼀个项⽬去使⽤mvn compile或mvn package进⾏编译和打包，对于使⽤Maven⽽⾔，你还是这样使⽤的话是⾮常⿇烦的。因为Maven给我们提供了聚合的功能。我们只需要再定义⼀个超级项⽬，然后在超级项⽬的中定义这个⼏个项⽬都是聚合到这个超级项⽬的。之后我们只需要对这个超级项⽬进⾏mvn compile，它就会把那些⼦模块项⽬都进⾏编译。1.2.2.1 被聚合项⽬和⼦模块项⽬在⽬录结构上是⽗⼦关系 还拿上⾯定义的projectA和projectB来举例⼦，现在假设我们需要把projectB聚合到projectA中。projectA和projectB的⽬录结构如下所⽰： ------projectA ------projectB ----- ------ 这个时候projectA的应该这样定义： 由上⾯的定义我们可以看到被聚合的项⽬的packaging类型应该为pom，⽽且⼀个项⽬可以有多个⼦模块项⽬。对于聚合这种情况，我们使⽤⼦模块项⽬的artifactId来作为module的值，表⽰⼦模块项⽬相对于被聚合项⽬的地址，在上⾯的⽰例中就表⽰⼦模块projectB是处在被聚合项⽬的⼦⽬录下，即与被聚合项⽬的处于同⼀⽬录。这⾥使⽤的module值是⼦模块projectB对应的⽬录名projectB，⽽不是⼦模块对应的artifactId。这个时候当我们对projectA进⾏mvn package命令时，实际上Maven也会对projectB进⾏打包。1.2.2.2 被聚合项⽬与⼦模块项⽬在⽬录结构上不是⽗⼦关系 那么当被聚合项⽬与⼦模块项⽬在⽬录结构上不是⽗⼦关系的时候，我们应该怎么来进⾏聚合呢？还是像继承那样使⽤relativePath元素吗？答案是⾮也，具体做法是在module元素中指定以相对路径的⽅式指定⼦模块。我们来看下⾯⼀个例⼦。 继续使⽤上⾯的projectA和projectB，还是需要把projectB聚合到projectA，但是projectA和projectB的⽬录结构不再是⽗⼦关系，⽽是如下所⽰的这种关系： ------projectA ------ ------projectB ------ 这个时候projectA的⽂件就应该这样定义： 注意看module的值是“../projectB”，我们知道“..”是代表当前⽬录的上层⽬录，所以它表⽰⼦模块projectB是被聚合项⽬projectA的⽂件所在⽬录（即projectA）的上层⽬录下⾯的⼦⽬录，即与projectA处于同⼀⽬录层次。注意，这⾥的projectB对应的是projectB这个项⽬的⽬录名称，⽽不是它的artifactId。1.2.2.3 聚合与继承同时进⾏ 假设有这样⼀种情况，有两个项⽬，projectA和projectB，现在我们需要projectB继承projectA，同时需要把projectB聚合到projectA。然后projectA和projectB的⽬录结构如下： ------projectA ------ ------projectB ------ 那么这个时候按照上⾯说的那样，projectA的中需要定义它的packaging为pom，需要定义它的modules，所以projectA的应该这样定义： ⽽projectB是继承⾃projectA的，所以我们需要在projectB的⽂件中新增⼀个parent元素，⽤以定义它继承的项⽬信息。所以projectB的⽂件的内容应该这样定义：1.2.3 依赖关系：依赖关系列表（dependency list）是POM的重要部分 项⽬之间的依赖是通过⽂件⾥⾯的dependencies元素下⾯的dependency元素进⾏的。⼀个dependency元素定义⼀个依赖关系。在dependency元素中我们主要通过依赖项⽬的groupId、artifactId和version来定义所依赖的项⽬。 先来看⼀个简单的项⽬依赖的⽰例吧，假设我现在有⼀个项⽬projectA，然后它⾥⾯有对junit的依赖，那么它的就类似以下这个样⼦：groupId, artifactId, version:描述了依赖的项⽬唯⼀标志。type：对应于依赖项⽬的packaging类型，默认是jar。scope:⽤于限制相应的依赖范围、传播范围。scope的主要取值范围如下（还有⼀个是在Maven2.0.9以后版本才⽀持的import，关于import作⽤域将在后⽂《Dependency介绍》中做介绍）：test:在测试范围有效，它在执⾏命令test的时候才执⾏，并且它不会传播给其他模块进⾏引⼊，⽐如 junit,dbunit 等测试框架。compile(default 默认):这是它的默认值，这种类型很容易让⼈产⽣误解，以为只有在编译的时候才是需要的，其实这种类型表⽰所有的情况都是有⽤的，包括编译和运⾏时。⽽且这种类型的依赖性是可以传递的。runtime:在程序运⾏的时候依赖，在编译的时候不依赖。provided:这个跟compile很类似，但是它表⽰你期望这个依赖项⽬在运⾏时由JDK或者容器来提供。这种类型表⽰该依赖只有在测试和编译的情况下才有效，在运⾏时将由JDK或者容器提供。这种类型的依赖性是不可传递的。⽐如 javaee：eclipse开发web环境中是没有javaee必须要⼿动添加。myeclipse新建web项⽬会有JavaEE(,...)web容器依赖的jar包，⼀般都是做开发的时候才使⽤。但是myeclipse不会把这些 jar包发布的，lib下你是找不到javaee引⼊的jar包,因为myeclipse发布项⽬的时候会忽略它。为什么？因为tomcat容器bin/lib已经存在了这个jar包了。system：这种类型跟provided类似，唯⼀不同的就是这种类型的依赖我们要⾃⼰提供jar包，这需要与另⼀个元素systemPath来结合使⽤。systemPath将指向我们系统上的jar包的路径，⽽且必须是给定的绝对路径。systemPath：上⾯已经说过了这个元素是在scope的值为system的时候⽤于指定依赖的jar包在系统上的位置的，⽽且是绝对路径。该元素必须在依赖的 jar包的scope为system时才能使⽤，否则Maven将报错。optional：当该项⽬本⾝作为其他项⽬的⼀个依赖时标记该依赖为可选项。假设现在projectA有⼀个依赖性projectB，我们把projectB这个依赖项设为optional，这表⽰projectB在projectA的运⾏时不⼀定会⽤到。这个时候如果我们有另⼀个项⽬projectC，它依赖于projectA，那么这个时候因为projectB对于projectA是可选的，所以Maven在建⽴projectC的时候就不会安装projectB，这个时候如果projectC确实需要使⽤到projectB，那么它就可以定义⾃⼰对projectB的依赖。当⼀个依赖是可选的时候，我们把optional元素的值设为true，否则就不设置optional元素。exclusions：考虑这样⼀种情况，我们的projectA依赖于projectB，然后projectB⼜依赖于projectC，但是在projectA⾥⾯我们不需要projectB依赖的projectC，那么这个时候我们就可以在依赖projectB的时候使⽤exclusions元素下⾯的exclusion排除projectC。这个时候我们可以这样定义projectA对projectB的依赖：
est
projectB
1.0-SNAPSHOT
est
projectC
1.3 属性在⽂件中我们可以使⽤${propertyName}的形式引⽤属性。是值的占位符，类似EL，类似ant的属性，⽐如${X}，可⽤于pom⽂件任何赋值的位置。有以下分类：
2023年8月1日发(作者：)
JAVA项⽬中是什么？有什么作⽤？转载⾃ 原创Alan_ckc
什么是POM？POM是项⽬对象模型(Project Object Model)的简称,它是Maven项⽬中的⽂件，使⽤XML表⽰，名称叫做。作⽤类似ant的⽂件，功能更强⼤。该⽂件⽤于管理：源代码、配置⽂件、开发者的信息和⾓⾊、问题追踪系统、组织信息、项⽬授权、项⽬的url、项⽬的依赖关系等等。事实上，在Maven世界中，project可以什么都没有，甚⾄没有代码，但是必须包含⽂件。概览下⾯是⼀个POM项⽬中的⽂件中包含的元素。注意，其中的modelVersion是4.0.0，这是当前仅有的可以被Maven2&3同时⽀持的POM版本，它是必须的。⼀，基本配置1.1 maven的协作相关属性 ⼀个最简单的的定义必须包含modelVersion、groupId、artifactId和version这四个元素，当然这其中的元素也是可以从它的⽗项⽬中继承的。在Maven中，使⽤groupId、artifactId和version组成groupdId:artifactId:version的形式来唯⼀确定⼀个项⽬：1.2 POM之间的关系，继承、聚合与依赖 我们知道Maven在建⽴项⽬的时候是基于Maven项⽬下的进⾏的，我们项⽬依赖的信息和⼀些基本信息都是在这个⽂件⾥⾯定义的。那如果当我们有多个项⽬要进⾏，这多个项⽬有些配置内容是相同的，有些是要彼此关联的，那如果按照传统的做法的话我们就需要在多个项⽬中都定义这些重复的内容。这⽆疑是⾮常耗费时间和不易维护的。好在Maven给我们提供了⼀个pom的继承和聚合的功能。 对于使⽤java的⼈⽽⾔，继承这个词⼤家应该都不陌⽣。要继承pom就需要有⼀个⽗pom，在Maven中定义了超级，任何没有申明⾃⼰⽗的都将默认继承⾃这个超级。 位置： 在Maven 版本中，⽐如，打开此Jar⽂件后，在包包t下会有的⽂件。 但是到了版本之后在： aven安装⽬录下的：/lib/中 orgapachemavenmode⽬录中的。 先来看⼀下这个超级的定义： 4.0.0 ${r}/target ${ory}/classes ${ctId}-${n} ${ory}/test-classes ${r}/src/main/java ${r}/src/main/scripts ${r}/src/test/java ${r}/src/main/resources ${r}/src/test/resources maven-antrun-plugin 1.3 maven-assembly-plugin 2.2-beta-5 maven-dependency-plugin 2.8 maven-release-plugin 2.3.2 ${ory}/site release-profile performRelease true true maven-source-plugin attach-sources jar true maven-javadoc-plugin attach-javadocs jar true maven-deploy-plugin true 对于⼀个来说有⼏个元素是必须定义的，⼀个是project根元素，然后就是它⾥⾯的modelVersion、groupId、artifactId和version。由上⾯的超级的内容我们可以看到中没有groupId、artifactId和version的定义，所以我们在建⽴⾃⼰的的时候就需要定义这三个元素。和java⾥⾯的继承类似，⼦会完全继承⽗中所有的元素，⽽且对于相同的元素，⼀般⼦中的会覆盖⽗中的元素，但是有⼏个特殊的元素它们会进⾏合并⽽不是覆盖。这些特殊的元素是：dependenciesdeveloperscontributorsplugin列表，包括plugin下⾯的reportsresources1.2.1 继承1.2.1.1 被继承项⽬与继承项⽬是⽗⼦⽬录关系 现在假设我们有⼀个项⽬projectA，它的定义如下： 然后我们有另⼀个项⽬projectB，⽽且projectB是跟projectA的⽂件处于同⼀个⽬录下，这时候如果projectB需要继承⾃projectA的话我们可以这样定义projectB的⽂件。 由projectB的⽂件的定义我们可以知道，当需要继承指定的⼀个Maven项⽬时，我们需要在⾃⼰的中定义⼀个parent元素，在这个元素中指明需要继承项⽬的groupId、artifactId和version。1.2.1.2 被继承项⽬与继承项⽬的⽬录结构不是⽗⼦关系 当被继承项⽬与继承项⽬的⽬录结构不是⽗⼦关系的时候，我们再利⽤上⾯的配置是不能实现Maven项⽬的继承关系的，这个时候我们就需要在⼦项⽬的⽂件定义中的parent元素下再加上⼀个relativePath元素的定义，⽤以描述⽗项⽬的⽂件相对于⼦项⽬的⽂件的位置。 假设我们现在还是有上⾯两个项⽬，projectA和projectB，projectB还是继承⾃projectA，但是现在projectB不在projectA的⼦⽬录中，⽽是与projectA处于同⼀⽬录中。这个时候projectA和projectB的⽬录结构如下： ------projectA ------ ------projectB ------ 这个时候我们可以看出projectA的相对于projectB的的位置是“../projectA/”，所以这个时候projectB的的定义应该如下所⽰：1.2.2 聚合 对于聚合这个概念搞java的⼈应该都不会陌⽣。先来说说我对聚合和被聚合的理解，⽐如说如果projectA聚合到projectB，那么我们就可以说projectA是projectB的⼦模块， projectB是被聚合项⽬，也可以类似于继承那样称为⽗项⽬。对于聚合⽽⾔，这个主体应该是被聚合的项⽬。所以，我们需要在被聚合的项⽬中定义它的⼦模块，⽽不是像继承那样在⼦项⽬中定义⽗项⽬。具体做法是：修改被聚合项⽬的中的packaging元素的值为pom在被聚合项⽬的中的modules元素下指定它的⼦模块项⽬对于聚合⽽⾔，当我们在被聚合的项⽬上使⽤Maven命令时，实际上这些命令都会在它的⼦模块项⽬上使⽤。这就是Maven中聚合的⼀个⾮常重要的作⽤。假设这样⼀种情况，你同时需要打包或者编译projectA、projectB、projectC和projectD，按照正常的逻辑我们⼀个⼀个项⽬去使⽤mvn compile或mvn package进⾏编译和打包，对于使⽤Maven⽽⾔，你还是这样使⽤的话是⾮常⿇烦的。因为Maven给我们提供了聚合的功能。我们只需要再定义⼀个超级项⽬，然后在超级项⽬的中定义这个⼏个项⽬都是聚合到这个超级项⽬的。之后我们只需要对这个超级项⽬进⾏mvn compile，它就会把那些⼦模块项⽬都进⾏编译。1.2.2.1 被聚合项⽬和⼦模块项⽬在⽬录结构上是⽗⼦关系 还拿上⾯定义的projectA和projectB来举例⼦，现在假设我们需要把projectB聚合到projectA中。projectA和projectB的⽬录结构如下所⽰： ------projectA ------projectB ----- ------ 这个时候projectA的应该这样定义： 由上⾯的定义我们可以看到被聚合的项⽬的packaging类型应该为pom，⽽且⼀个项⽬可以有多个⼦模块项⽬。对于聚合这种情况，我们使⽤⼦模块项⽬的artifactId来作为module的值，表⽰⼦模块项⽬相对于被聚合项⽬的地址，在上⾯的⽰例中就表⽰⼦模块projectB是处在被聚合项⽬的⼦⽬录下，即与被聚合项⽬的处于同⼀⽬录。这⾥使⽤的module值是⼦模块projectB对应的⽬录名projectB，⽽不是⼦模块对应的artifactId。这个时候当我们对projectA进⾏mvn package命令时，实际上Maven也会对projectB进⾏打包。1.2.2.2 被聚合项⽬与⼦模块项⽬在⽬录结构上不是⽗⼦关系 那么当被聚合项⽬与⼦模块项⽬在⽬录结构上不是⽗⼦关系的时候，我们应该怎么来进⾏聚合呢？还是像继承那样使⽤relativePath元素吗？答案是⾮也，具体做法是在module元素中指定以相对路径的⽅式指定⼦模块。我们来看下⾯⼀个例⼦。 继续使⽤上⾯的projectA和projectB，还是需要把projectB聚合到projectA，但是projectA和projectB的⽬录结构不再是⽗⼦关系，⽽是如下所⽰的这种关系： ------projectA ------ ------projectB ------ 这个时候projectA的⽂件就应该这样定义： 注意看module的值是“../projectB”，我们知道“..”是代表当前⽬录的上层⽬录，所以它表⽰⼦模块projectB是被聚合项⽬projectA的⽂件所在⽬录（即projectA）的上层⽬录下⾯的⼦⽬录，即与projectA处于同⼀⽬录层次。注意，这⾥的projectB对应的是projectB这个项⽬的⽬录名称，⽽不是它的artifactId。1.2.2.3 聚合与继承同时进⾏ 假设有这样⼀种情况，有两个项⽬，projectA和projectB，现在我们需要projectB继承projectA，同时需要把projectB聚合到projectA。然后projectA和projectB的⽬录结构如下： ------projectA ------ ------projectB ------ 那么这个时候按照上⾯说的那样，projectA的中需要定义它的packaging为pom，需要定义它的modules，所以projectA的应该这样定义： ⽽projectB是继承⾃projectA的，所以我们需要在projectB的⽂件中新增⼀个parent元素，⽤以定义它继承的项⽬信息。所以projectB的⽂件的内容应该这样定义：1.2.3 依赖关系：依赖关系列表（dependency list）是POM的重要部分 项⽬之间的依赖是通过⽂件⾥⾯的dependencies元素下⾯的dependency元素进⾏的。⼀个dependency元素定义⼀个依赖关系。在dependency元素中我们主要通过依赖项⽬的groupId、artifactId和version来定义所依赖的项⽬。 先来看⼀个简单的项⽬依赖的⽰例吧，假设我现在有⼀个项⽬projectA，然后它⾥⾯有对junit的依赖，那么它的就类似以下这个样⼦：groupId, artifactId, version:描述了依赖的项⽬唯⼀标志。type：对应于依赖项⽬的packaging类型，默认是jar。scope:⽤于限制相应的依赖范围、传播范围。scope的主要取值范围如下（还有⼀个是在Maven2.0.9以后版本才⽀持的import，关于import作⽤域将在后⽂《Dependency介绍》中做介绍）：test:在测试范围有效，它在执⾏命令test的时候才执⾏，并且它不会传播给其他模块进⾏引⼊，⽐如 junit,dbunit 等测试框架。compile(default 默认):这是它的默认值，这种类型很容易让⼈产⽣误解，以为只有在编译的时候才是需要的，其实这种类型表⽰所有的情况都是有⽤的，包括编译和运⾏时。⽽且这种类型的依赖性是可以传递的。runtime:在程序运⾏的时候依赖，在编译的时候不依赖。provided:这个跟compile很类似，但是它表⽰你期望这个依赖项⽬在运⾏时由JDK或者容器来提供。这种类型表⽰该依赖只有在测试和编译的情况下才有效，在运⾏时将由JDK或者容器提供。这种类型的依赖性是不可传递的。⽐如 javaee：eclipse开发web环境中是没有javaee必须要⼿动添加。myeclipse新建web项⽬会有JavaEE(,...)web容器依赖的jar包，⼀般都是做开发的时候才使⽤。但是myeclipse不会把这些 jar包发布的，lib下你是找不到javaee引⼊的jar包,因为myeclipse发布项⽬的时候会忽略它。为什么？因为tomcat容器bin/lib已经存在了这个jar包了。system：这种类型跟provided类似，唯⼀不同的就是这种类型的依赖我们要⾃⼰提供jar包，这需要与另⼀个元素systemPath来结合使⽤。systemPath将指向我们系统上的jar包的路径，⽽且必须是给定的绝对路径。systemPath：上⾯已经说过了这个元素是在scope的值为system的时候⽤于指定依赖的jar包在系统上的位置的，⽽且是绝对路径。该元素必须在依赖的 jar包的scope为system时才能使⽤，否则Maven将报错。optional：当该项⽬本⾝作为其他项⽬的⼀个依赖时标记该依赖为可选项。假设现在projectA有⼀个依赖性projectB，我们把projectB这个依赖项设为optional，这表⽰projectB在projectA的运⾏时不⼀定会⽤到。这个时候如果我们有另⼀个项⽬projectC，它依赖于projectA，那么这个时候因为projectB对于projectA是可选的，所以Maven在建⽴projectC的时候就不会安装projectB，这个时候如果projectC确实需要使⽤到projectB，那么它就可以定义⾃⼰对projectB的依赖。当⼀个依赖是可选的时候，我们把optional元素的值设为true，否则就不设置optional元素。exclusions：考虑这样⼀种情况，我们的projectA依赖于projectB，然后projectB⼜依赖于projectC，但是在projectA⾥⾯我们不需要projectB依赖的projectC，那么这个时候我们就可以在依赖projectB的时候使⽤exclusions元素下⾯的exclusion排除projectC。这个时候我们可以这样定义projectA对projectB的依赖：
est
projectB
1.0-SNAPSHOT
est
projectC
1.3 属性在⽂件中我们可以使⽤${propertyName}的形式引⽤属性。是值的占位符，类似EL，类似ant的属性，⽐如${X}，可⽤于pom⽂件任何赋值的位置。有以下分类：
发布评论