没有合适的资源?快使用搜索试试~ 我知道了~
maven权威中文指南,从基础背景讲起,用于项目构建,自动化持续集成
资源推荐
资源详情
资源评论
Maven 权威指南
来源:http://books.sonatype.com/maven‐book/reference_zh/public‐book.html
整理:忆雪网络 http://www.yisnow.com
仅方便个人学习交流,请勿用于商业用途
邮箱:xuebaiyouling@163.com/QQ:370417982
Chapter 1. 介绍 Apache Maven
1.1. Maven... 它是什么?
1.2. 约定优于配置(Convention Over Configuration)
1.3. 一个一般的接口
1.4. 基于 Maven 插件的全局性重用
1.5. 一个“项目”的概念模型
1.6. Maven 是 Ant 的另一种选择么?
1.7. 比较 Maven 和 Ant
1.8. 总结
虽然网络上有许多 Maven 的参考文章,但是没有一篇单独的,编写规范的介绍 Maven
的文字,它需要是一本细心编排的入门指南和参考手册。 我们做的,正是试图提供这
样的,包含许多使用参考的文字。
1.1. Maven... 它是什么?
如何回答这个问题要看你怎么看这个问题。 绝大部分 Maven 用户都称 Maven 是
一个"构建工具":一个用来把源代码构建成可发布的构件的工具。 构建工程师和项目
经理会说 Maven 是一个更复杂的东西:一个项目管理工具。那么区别是什么? 像 Ant
这样的构建工具仅仅是关注预处理,编译,打包,测试和分发。像 Maven 这样的一
个项目管理工具提供了构建工具所提供功能的超集。 除了提供构建的功能,Maven 还
可以生成报告,生成 Web 站点,并且帮助推动工作团 队成员间的交流。
一个更正式的 Apache Maven
的定义: Maven 是一个项目管理工具,它包含了一
个项目对象模型 (Project Object Model),一组标准集合,一个项目生命周期(Project
Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行
定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。 当你使用 Maven 的
时候,你用一个明确定义的项目对象模型来描述你的项目,然后 Maven 可以应用横
切的逻辑,这些逻辑来自一组共享的(或者自定义的)插件。
别让 Maven 是一个"项目管理"工具的事实吓跑你。如果你只是在找一个构建工具,
Maven 能做这个工作。 事实上,本书的一些章节将会涉及使用 Maven 来构建和分发
你的项目。
1.2. 约定优于配置(Convention Over Configuration)
约定优于配置是一个简单的概念。 系统,类库,框架应该假定合理的默认值,而
非要求提供不必要的配置。 流行的框架如 Ruby on Rails
和 EJB3 已经开始坚持这
些原则,以对像原始的 EJB 2.1 规范那样的框架的配置复杂度做出反应。 一个约定
优于配置的例子就像 EJB3 持久化,将一个 特殊的 Bean 持久化,你所需要做的只是
将这个类标注为
@Entity 。 框架将会假定表名和列名是基于类名和属性名。 系统也
提供了一些钩子,当有需要的时候你可以重写这些名字,但是,在大部分情况下,你会
发现使用框架提供的默认值会让你的项目运行的更快。
Maven 通过给项目提供明智的默认行为来融合这个概念。 在没有自定义的情况
下,源代码假定是在
${basedir}/src/main/java,资源文件假定是在
${basedir}/src/main/resources 。测试代码假定是在 ${basedir}/src/test 。
项目假定会产生一个 JAR 文件。Maven 假定你想要把编译好的字节码放到
${basedir}/target/classes 并且在 ${basedir}/target 创建一个可分发的 JAR
文件。 虽然这看起来无关紧要,但是想想大部分基于 Ant 的构建必须为每个子项目定
义这些目录。 Maven 对约定优于配置的应用不仅仅是简单的目录位置,Maven 的核
心插件使用了一组通用的约定,以用来编译源代码,打包可分发的构件,生成 web 站
点,还有许多其他的过程。 Maven 的力量来自它的"武断",它有一个定义好的生命周
期和一组知道如何构建和装配软件的通用插件。如果你遵循这些约定,Maven 只需要
几乎为零的工作——仅仅是将你的源代码放到正确的目录,Maven 将会帮你处理剩下
的事情。
使用“遵循约定优于配置”系统的一个副作用是用户可能会觉得他们被强迫使用一
种特殊的方法。 当然 Maven 有一些核心观点不应该被怀疑,但是其实很多默认行为
还是可配置的。 例如项目源码的资源文件的位置可以被自定义,JAR 文件的名字可以
被自定义,在开发自定义插件的时候,几乎任何行为可以被裁剪以满足你特定的环境需
求。 如果你不想遵循约定,Maven 也会允许你自定义默认值来适应你的需求。
1.3. 一个一般的接口
在 Maven 为构建软件提供一个一般的接口之前,每个单独的项目都专门有人来管
理一个完全自定义的构建系统。开发人员必须在开发软件之外去学习每个他们要参与的
新项目的构建系统的特点。 在 2001 年,构建一个项目如 Turbine
和构建另外一个
项目如 Tomcat
,两者方法是完全不同的。如果一个新的进行静态源码分析的源码分
析工具面世了,或者如果有人开发了一个新的单元测试框架,每个人都必须放下手头的
工作去想办法使这个新东西适应每个项目的自定义构建环境。 如何运行单元测试?世
界上有一千种不同的答案。构建环境由无数无休止的关于工具和构建程序的争论所描述
刻画。Maven 之前的时代是低效率的时代,是“构建工程师”的时代。
现在,大部分开源开发者已经或者正在使用 Maven 来管理他们新的软件项目。这种
转变不仅仅是开发人员从一种构建工具转移到另外一种构建工具,更是开发人员开始为
他们的项目采用一种一般的接口。随着软件系统变得越来越模块化,构建系统变得更复
杂,而项目的数量更是如火箭般飞速上升。在 Maven 之前,当你想要从 Subversion
签出一个项目如 Apache ActiveMQ
或 Apache ServiceMix ,然后从源码进行构
建,你需要为每个项目留出一个小时来理解给它的构建系统。这个项目需要构建什么?
需要现在什么类库?把类库放哪里?构建中我该运行什么目标?最好的情况下,理解一
个新项目的构建需要几分钟,最坏的情况下(例如 Jakarta 项目的旧的 Servlet API
实现),一个项目的构建特别的困难,以至于花了几个小时以后,新的贡献者也只能编
辑源码和编译项目。现在,你只要签出源码,然后运行: mvn install 。虽 然 Maven
有很多优点,包括依赖管理和通过插件重用一般的构建逻辑,但它成功的最核心原因是
它定义了构建软件的一般的接口。每当你看到一个使用 Maven 的项目如 Apache
Wicket ,你就可以假设你能签出它的源码然后使用 mvn install 构建它,没什么好
争论的。你知道点火开关在哪里,你知道油门在右边,刹车在左边。
1.4. 基于 Maven 插件的全局性重用
Maven 的核心其实不做什么实际的事情,除了解析一些 XML 文档,管理生命周
期与插件之外,它什么也不懂。Maven 被设计成将主要的职责委派给一组 Maven 插
件,这些插件可以影响 Maven 生命周期,提供对目标的访问。绝大多数 Maven 的
动作发生于 Maven 插件的目标,如编译源码,打包二进制代码,发布站点和其它构
建任务。你从 Apache 下载的 Maven 不知道如何打包 WAR 文件,也不知道如何
运行单元测试,Maven 大部分的智能是由插件实现的,而插件从 Maven 仓库获得。
事实上,第一次你用全新的 Maven 安装运行诸如 mvn install 命令的时候,它会
从中央 Maven 仓库下载大部分核心 Maven 插件。这不仅仅是一个最小化 Maven
分发包大小的技巧,这种方式更能让你升级插件以给你项目的构建提高能力。Maven
从远程仓库获取依赖和插件的这一事实允许了构建逻辑的全局性重用。
Maven Surefire 插件是负责运行单元测试的插件。从版本 1.0 发展到目前广泛使用
的在 JUnit 基础上增加了 TestNG 测试框架支持的版本。这种发展并没有破坏向后兼
容性,如果你使用之前 Surefire 插件编译运行你的 JUnit 3 单元测试,然后你升级
到了最新版本的 Surefire 插件,你的测试仍然能成功运行。但是,我们又获得了新的
功能,如果你想使用 TestNG 运行单元测试,那么感谢 Surefire 插件的维护者,你
已经可以使用 TestNG 了。你也能运行支持注解的 JUnit 4 单元测试。不用升级
Maven 安装或者新装任何软件,你就能获得这些功能。更重要的是,除了 POM 中一
个插件的版本号,你不需要更改你项目的任何东西。
这种机制不仅仅适用于 Surefire 插件,项目使用 Compiler 插件进行编译,通过 Jar
插件变成 JAR 文件,还有一些插件生成报告,运行 JRuby 和 Groovy 的代码,以
及一些用来向远程服务器发布站点的插件。Maven 将一般的构建任务抽象成插件,同
时这些插件得到了很好的维护以及全局的共享,你不需要从头开始自定义你项目的构建
系统然后提供支持。你完全可以从 Maven
插件获益,这些插件有人维护,可以从远
程仓库下载到。这就是基于 Maven 插件的全局性重用。
1.5. 一个“项目”的概念模型
Maven 维护了一个项目的模型,你不仅仅需要把源码编译成字节码,你还需要开发软
件项目的描述信息,为项目指定一组唯一的坐标。你要描述项目的的属性。项目的许可
证是什么?谁开发这个项目,为这个项目做贡献?这个项目依赖于其它什么项目没有?
Maven 不仅仅是一个“构建工具”,它不仅仅是在类似于 make 和 Ant 的工具的基础
上的改进,它是包含了一组关于软件项目和软件开发的语义规则的平台。这个基于每一
个项目定义的模型实现了如下特征:
依赖管理
由于项目是根据一个包含组标识符,构件标识符和版本的唯一的坐标定义的。
项目间可以使用这些坐标来声明依赖。
远程仓库
和项目依赖相关的,我们可以使用定义在项目对象模型(POM)中的坐标来创
建 Maven 构件的仓库。
全局性构建逻辑重用
插件被编写成和项目模型对象(POM)一起工作,它们没有被设计成操作某一
个已知位置的特定文件。一切都被抽象到模型中,插件配置和自定义行为都在
模型中进行。
工具可移植性/集成
像 Eclipse,NetBeans,和 InteliJ 这样的工具现在有共同的地方来找到项目
的信息。在 Maven 出现之前,每个 IDE 都有不同的方法来存储实际上是自
定义项目对象模型(POM)的信息。Maven 标准化了这种描述,而虽然每个 IDE
仍然继续维护它的自定义项目文件,但这些文件现在可以很容易的由模型生成。
便于搜索和过滤构件
像 Nexus 这样的工具允许你使用存储在 POM 中的信息对仓库中的内容进行
索引和搜索。
Maven 为软件项目的语义一致性描述的开端提供了一个基础。
1.6. Maven 是 Ant 的另一种选择么?
当然,Maven 是 Ant 的另一种选择,但是 Apache Ant 继续是一个伟大的,被广泛
使用的工具。它已经是多年以来 Java 构建的统治者,而你很容易的在你项目的
Maven 构建中集成 Ant 构建脚本。这是 Maven 项目一种很常见的使用模式。而另
一方面,随着越来越多的开源项目转移到 Maven 用它作为项目管理平台,开发人员
开始意识到 Maven 不仅仅简化了构建管理任务,它也帮助鼓励开发人员的软件项目
使用通用的接口。Maven 不仅仅是一个工具,它更是一个平台,当你只是将 Maven 考
虑成 Ant 的另一种选择的时候,你是在比较苹果和橘子。“Maven”包含了很多构建工
具以外的东西。
有一个核心观点使得所有的关于 Maven 和. Ant, Maven 和 Buildr, Maven 和
Grandle 的争论变得无关紧要。Maven 并不是完全根据你构建系统的机制来定义的,
它不是为你构建的不同任务编写脚本,它提倡一组标注,一个一般的接口,一个生命周
期,一个标准的仓库格式,一个标准的目录布局,等等。它当然也不太在意 POM 的格
式正好是 XML 还是 YAML 还是 Ruby。它比这些大得多,Maven 涉及的比构建工
具本身多得多。当本书讨论 Maven 的时候,它也设计到支持 Maven 的软件,系统
和标准。Buildr,Ivy,Gradle,所有这些工具都和 Maven 帮助创建的仓库格式交互,
而你可以很容易的使用如 Nexus 这样的工具来支持一个完全由 Buildr 编写的构建。
Nexus 将在本书后面介绍。
虽然 Maven 是很多类似工具的另一个选择?但社区需要向前发展,就要看清楚技术
是资本经济中不友好的竞争者之间持续的、零和的游戏。这可能是大企业之前相互关联
的方式,但是和开源社区的工作方式没太大关系。“谁是胜利者?Ant 还是 Maven”这
个大标题没什么建设性意义。如果你非要我们来回答这个问题,我们会很明确的说作为
构建的基本技术,Maven 是 Ant 的更好选择;同时,Maven 的边界在持续的移动,
Maven 的社区也在持续的是试图找到新的方法,使其更通用,互操作性更好,更易协
同工作。Maven 的核心财产是声明性构建,依赖管理,仓库管理,基于插件的高度和
重用,但是当前,和开源社区相互协作以降低”企业级构建“的低效率这个目标来比,这
些想法的特定实现没那么重要。
1.7. 比较 Maven 和 Ant
虽然上一节应该已经让你确信本书的作者没有兴趣挑起 Apache Ant 和 Apache
Maven 之间的争执,但是我们认识到许多组织必须在 Apache Ant 和 Apache
Maven 之间做一个选择。本节我们对比一下这两个工具。
Ant 在构建过程方面十分优秀,它是一个基于任务和依赖的构建系统。每个任务包含一
组由 XML 编码的指令。有
copy 任务和 javac 任务,以及 jar 任务。在你使用 Ant
的时候,你为 Ant 提供特定的指令以编译和打包你的输出。看下面的例子,一个简单
的
build.xml 文件:
Example 1.1. 一个简单的 Ant build.xml 文件
<project name="my-project" default="dist" basedir=".">
<description>
simple example build file
</description>
<
!-- set global properties for this build --
>
<property name="src" location="src/main/java"/>
<property name="build" location="target/classes"/>
<property name="dist" location="target"/>
<target name="init">
<
!-- Create the time stamp --
>
<tstamp/>
<
!-- Create the build directory structure used by compile --
>
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source " >
<
!-- Compile the java code from ${src} into ${build} --
>
<javac srcdir="${src}" destdir="${build}"/>
</target>
剩余274页未读,继续阅读
资源评论
xigedanganxi
- 粉丝: 23
- 资源: 13
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功