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仓库之外的类库文件 |