Pom文件中的groupId、artifactId、version和name,这三个元素定义了一个项目的基本的坐标,在Maven世界中,任何的jar、pom或者war都是基于这些基本的坐标惊醒区分。
groupId:定义了项目属于哪个组,这个项目组往往和项目所在的组织或公司存在关联。譬如在googlecode上建立了一个名为myapp的项目,那么groupId就应该是
com.googlecode.myapp。这里conup项目的groupId应该是cn.edu.nju.moon.conup
artifactId:定义了当前Maven项目在组中唯一的ID,我们为这个Hello World项目定义了artifactId为hello-world
version:指定了Hello World项目当前的版本。
name:声明了一个对于用户更为友好的项目名称
一个依赖的声明包括如下的一些元素:
1 <project> 2 ... 3 <dependencies> 4 <dependency> 5 <groupId>...</groupId> 6 <artifactId>...</artifactId> 7 <version>...</version> 8 <type>...</type> 9 <scope>...</scope> 10 <optional>...</optional> 11 <exclusions> 12 <exclusion> 13 ... 14 </exclusion> 15 </exclusions> 16 </dependency> 17 </dependencies> 18 </project>
1.scope 依赖范围
首先需要知道,Maven在编译项目主代码的时候需要使用一套classpath,其次,Maven在编译和执行测试的时候会使用另外一套classpath。最后,实际运行Maven项目的时候,又会使用一套
classpath。Maven有以下几种依赖范围:
a.compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效,在编译、测试、运行的时候都需要使用该依赖。
b.test:测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此依赖。典型的例子是junit,它只有在编译测试代码及运行测试的时候才需要。
c.provided:已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目时候,由于容器已经提供,就不需要Maven重复地引入一遍
d.runtime:运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动
f.system:系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件的路径。此依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构件的不可移植,需谨慎使用。
g.import:导入依赖方位。该依赖范围不会对三种classpath产生实际的影响。
依赖范围(Scope) | 对于编译classpath有效 | 对于测试classpath有效 | 对于运行时classpath有效 | 例子 |
compile | Y | Y | Y | sprint-core |
test | - | Y | - | junit |
provided | Y | Y | - | servlet-api |
runtime | - | Y | Y | JDBC驱动实现 |
system | y | Y | - | 本地的,Maven仓库之外的类库文件 |