(四)《Maven实战》读书笔记 —— Maven坐标和依赖

第四章:坐标和依赖

正如第1章所述,Maven的一大功能是管理项目依赖。为了能自动化地解析任何一个Java构件,Maven就必须将它们唯一标识,这就是依赖管理的底层基础——坐标

4.1 何为Maven坐标

关于坐标(Coordinate),大家最熟悉的定义应该来自于立体几何。在一个立体坐标系中,该立体空间内的任何一个点,都能够用坐标(x,y,z)唯一标识。在实际生活中,我们可以将地址看成一种坐标。省市县等一系列信息同样可以唯一标识城市中的任一居住地址,邮局和快递公司正是基于这样一种坐标进行邮件寄送的。

对应于几何中的点和城市中的地址,Maven世界中拥有数量非常巨大的构件(如jar),在Maven为这些构件引入坐标概念之前,我们无法使用任何一种方式来唯一标识所有这些构件。因此,当需要用到Spring Framework依赖的时候,大家会去Spring Framework网站寻找,当需要用到log4j依赖的时候,大家又会去Apache网站寻找。又因为各个项目的网站风格迥异,大量的时间花费在了搜索、浏览网页和下载构件。Maven定义了这样的一组规则:世界上任何一个构件都可以使用Maven坐标唯一标识,Maven坐标的元素包括GroupId、artfactId、version、packaging、classifier,现在只要我们提供正确的坐标,Maven就能够帮助我们找到对应的构件。

也许你会奇怪,“Maven是从哪里下载构件呢?”答案很简单,Maven内置了一个中央仓库地址(http://repo1.maven.org/maven2),该中央仓库包含了世界上大部分流行的开源项目构件,Maven会在需要的时候去那里下载。

在我们开发Maven项目的时候,也需要定义适当的坐标,这是Maven强制要求的。在这个基础上,其它的Maven项目才能引用该项目生成的构件。

4.2 坐标详解

Maven坐标为各种构件引入了秩序,任何一个构件都必须明确定义自己的坐标,而一组Maven坐标是通过一些元素定义的,它们是GroupId、artfactId、version、packaging、classifier。坐标定义如下:

org.sonatype.nexus
nexus-indexer
2.0.0
jar
  • groupId:定义当前Maven项目所属的实际项目。首先,Maven项目和实际项目不一定是一对一的关系。比如SpringFramework这一实际项目,其对应的Maven项目会有很多,如spring-core、spring-context等。这是由于Maven中模块的概念,因此一个实际项目往往会被划分为很多模块。推荐的做法是使用项目隶属的组织或公司的反向域名作为前缀,后跟实际项目名称。上例中,GroupId为org.sonatype.nexus,org.sonatype表示Sonatype公司建立的一个非营利性组织,nexus表示Nexus这一实际项目。
  • artifactId:定义实际项目中的一个Maven项目模块,推荐的做法是使用实际项目名称作为前缀,后跟模块名称。上例中,artfactId是nexus-indexer,使用了实际项目名nexus作为前缀,这样做的好处是方便寻找实际构件。默认情况下,Maven生成的构件,其文件名会以artfactId作为开头
  • version:定义Maven项目当前所处的版本,如上例中nexus-indexer的版本是2.0.0。
  • packaging:定义项目的打包方式。首先,打包方式通常于所生成构件的文件扩展名对应,如上例中packaging为jar,最终的文件名为nexus-indexer-2.0.0.jar。其次,打包方式会影响到构件的生命周期。
  • classifier:该元素用来帮助定义构建输出的一些附属构件。附属构件与主构件对应,如上例中的主构件是nexus-indexer-2.0.0.jar,该项目可能还会用过使用一些插件生成nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些附属构件,其中包含了Java文档和源代码。这时候,javadoc和sources就是这两个附属构件的classifier。这样附属构件也就拥有了自己唯一的坐标。

上述的5个元素中,groupId、artfactId、version是必须定义的,packaging是可选的(默认的打包方式的jar),而classifier是不能直接定义的。

4.3 依赖的配置

一个依赖的声明可以包含如下的一些元素:


  ......

  
  	
  		org.springframework   //项目名称(依赖的基本坐标)
  		spring-core     //模块名称(依赖的基本坐标)
  		2.5.6                 //所处版本(依赖的基本坐标)
                ...                         //打包类型(默认jar)
                ...                       //依赖范围(默认compile)
                ...                 //依赖是否可选
                                             //排除传递性依赖
                      ...
                
  	
  
  ......
                                        

4.4 依赖范围

Maven在编译项目主代码的时候需要使用一套classpath,Maven在编译和执行测试的时候会使用一套classpath,Maven在实际运行项目的时候会使用一套classpath。依赖范围就是用来控制依赖与classpath(编译classpath、测试classpath、运行classpath)的关系:

  • compile:编译依赖范围(默认)。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。
  • test:测试依赖范围。使用此依赖范围的Maven依赖,只对测试classpath有效,在编译主代码或者运行项目的时候将无法使用此类依赖。典型的例子是JUnit,它只有在编译测试代码及运行测试的时候才需要。
  • provided:已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但是在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但是在运行项目的时候,由于容器已经提供,就不需要Maven重复引入。
  • runtime:运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供JDBC接口,只有在执行测试和运行项目的时候才需要实现上述接口的具体JDBC驱动。
  • system:系统依赖范围。使用此依赖范围的Maven依赖,和provided依赖范围一致。但是使用system范围时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往于本机系统绑定,可能造成构件的不可移植,因此应该慎重使用。
  • import(Maven 2.0.9及以上):导入依赖范围。该依赖范围不会对三种classpath产生实际的影响【后续完善】。

4.5 传递性依赖

4.5.1 何为传递性依赖

 

转载于:https://www.cnblogs.com/flyingweb/p/8492291.html

你可能感兴趣的:(java,runtime)