maven 笔记1

 

$ mvn help:effective-pom

 

一旦你运行了此命令，你应该能看到一个大得多的POM，它暴露了Maven的默认设置

• 如果你运行mvn install命令，Maven会把我们项目的构件安装到本地仓库。

  指定编译版本....<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>....

 

• 这是Maven最强大的特征之一，它支持了传递性依赖（transitive dependencies）。
• $ mvn siteMaven提供了很完整的可配置的报告，像Clover报告检查单元测试覆盖率，JXR报告生成HTML源代码相互间引用，这在代码审查的时候非常有用，PMD报告针对各种编码问题来分析源代码，JDepend报告分析源代码中各个包之间的依赖。通过在pom.xml中配置那些报告被包含在构建中，站点报告就可以被定制了。

 

• Exec 插件允许你运行 Java 类和其它脚本。 它不是 Maven 核心插件，但它可以从 Codehaus 的 Mojo 项目得到。想要查看 Exec 插件的完整描述，运行：

$ mvn help:describe -Dplugin=exec -Dfull

• 跳过单元测试 

      $ mvn install -Dmaven.test.skip=true

 

使用Maven Dependency插件进行优化

 

$ mvn dependency:analyze

$ mvn dependency:tree

• 项目对象模型

 

•  super pom,它是Maven安装的一部分，可以在/usr/local/maven/lib中的maven-2.0.9-uber.jar文件中找到。如果你看一下这个JAR文件，你会看到在包org.apache.maven.project下看到一个名为pom-4.0.0.xml的文件。

这个超级POM定义了一些由所有项目继承的标准配置变量。对这些变量的简单解释如下：

	默认的超级POM定义了一个单独的远程Maven仓库，ID为central。这是所有Maven客户端默认配置访问的中央Maven仓库。该配置可以通过一个自定义的settings.xml文件来覆盖。注意这个默认的超级POM关闭了从中央Maven仓库下载snapshot构件的功能。如果你需要使用一个snapshot仓库，你就要在你的pom.xml或者settings.xml中自定义仓库设置。Settings和profile将会在Chapter 11, 构建Profile中和Section A.1, “简介”中的Appendix A, 附录: Settings细节小节中具体介绍。
	中央Maven仓库同时也包含Maven插件。默认的插件仓库就是这个中央仓库。Snapshot被关闭了，而且更新策略被设置成了“从不”，这意味着Maven将永远不会自动更新一个插件，即使新版本的插件发布了。
	build元素设置Maven标准目录布局中那些目录的默认值。
	从Maven 2.0.9开始，超级POM为核心插件提供了默认版本。这么做是为那些没有在它们POM中指定插件版本的用户提供一些稳定性。

 

 

版本号

  一个Maven项目发布版本号用version编码，用来分组和排序发布。Maven中的版本包含了以下部分：主版本，次版本，增量版本，和限定版本号。

 

变量

  Maven提供了三个隐式的变量，可以用来访问环境变量，POM信息，和Maven Settings：

env

env变量 暴露了你操作系统或者shell的环境变量。例如，在Maven POM中一个对/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin:/usr/local/bin:/usr/local/maven/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/java/latest/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/bin:/usr/local/bin的引用将会被/usr/local/bin:/usr/local/maven/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/java/latest/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/bin:/usr/local/bin环境变量替换（或者Windows中的%PATH%）。

project

project变量暴露了POM。你可以使用点标记（.）的路径来引用POM元素的值。例如，在本节中我们使用过groupId和artifactId来设置构建配置中的finalName元素。这个属性引用的语法是：org.sonatype.mavenbook-${project.artifactId}。

settings

settings变量暴露了Maven settings信息。可以使用点标记（.）的路径来引用settings.xml文件中元素的值。例如，${settings.offline}会引用~/.m2/settings.xml文件中offline元素的值。

Note

你可能在老的构建中看到使用${pom.xxx}或者仅仅${xxx}来引用POM属性。这些方法已被弃用，我们只应该使用${project.xxx}。

除了这三个隐式的变量，你还可以引用系统属性，以及任何在Maven POM中和构建profile中自定义的属性组。

   Java系统属性

所有可以通过java.lang.System中getProperties()方法访问的属性都被暴露成POM属性。

依赖范围

<dependency> 
<groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>3.8.1</version>
 <scope>test</scope>
 </dependency>

  

compile（编译范围）

compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。编译范围依赖在所有的classpath中可用，同时它们也会被打包。

provided（已提供范围）

provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如，如果你开发了一个web应用，你可能在编译classpath中需要可用的Servlet API来编译一个servlet，但是你不会想要在打包好的WAR中包含这个ServletAPI；这个Servlet API JAR由你的应用服务器或者servlet容器提供。已提供范围的依赖在编译classpath（不是运行时）可用。它们不是传递性的，也不会被打包。

runtime（运行时范围）

runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC APIJAR，而只有在运行的时候才需要JDBC驱动实现。

test（测试范围）

test范围依赖 在一般的 编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。测试范围依赖在之前的???中介绍过。

system（系统范围）

system范围依赖与provided类似，但是你必须显式的提供一个对于本地系统中JAR文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven仓库中引用依赖）。

 

可选依赖

编译这个项目的时候你需要两个依赖类库，但是你不希望在使用你类库的项目中，这两个依赖类库同时作为传递性运行时依赖出现。你可以使用如Example 9.4, “声明可选依赖”中的可选依赖来完成这个任务。

<dependency> 
<groupId>swarmcache</groupId> 
<artifactId>swarmcache</artifactId>
 <version>1.0RC2</version> 
<optional>true</optional> 
</dependency>

  

依赖版本界限

Example 9.6. 指定一个依赖界限：JUnit <= 3.8.1

<dependency>
 <groupId>junit</groupId> 
<artifactId>junit</artifactId> 
<version>[,3.8.1]</version>

 <scope>test</scope> 
</dependency>

    

冲突解决

“排除一个传递性依赖”

<dependency>
 <groupId>org.sonatype.mavenbook</groupId>
 <artifactId>project-a</artifactId> 
<version>1.0</version>
 <exclusions> 
<exclusion> 
<groupId>org.sonatype.mavenbook</groupId>
 <artifactId>project-b</artifactId> 
</exclusion> 
</exclusions> 
</dependency>

  

多模块项目

文件系统上的目录结构也反映了该模块关系。Figure 9.3, “多模块项目关系”中的一组项目拥有如下的目录结构：

top-group/pom.xml
top-group/sub-group/pom.xml
top-group/sub-group/project-a/pom.xml
top-group/sub-group/project-b/pom.xml
top-group/project-c/pom.xml