Maven学习笔记

maven学习笔记
--------------------------------------------------------------------------------

1、maven概述(Introduction)

--------------------------------------------------------------------------------

Maven, a Yiddish word meaning accumulator of knowledge, was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

The result is a tool that can now be used for building and managing any Java-based project. We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.

摘自http://maven.apache.org/what-is-maven.html

意思是:maven,是一个第绪语的词,意味着知识池(专家),开始被用作Jakarta Turbine项目中简化构建方法的尝试。有许多项目都有它们自己的Ant构建文件(这些文件都有很小的不同),JAR包也都是被提交到CVS。

我们想要有,一个标准的构建项目的方法,一个项目构成的清晰定义,一个发布项目信息的容易方法,一个共享能访问许多项目的JAR包的方法。

因此产生了一个能构建和管理任何基于JAVA的项目的工具。我们希望我们已经创出了能够使JAVA开发者在日常工作中感到更加的容易以及帮助其对任何基于JAVA项目的理解的东西。

2、maven的构建生命周期(Build Lifecycle)

--------------------------------------------------------------------------------

Each of these build lifecycles is defined by a different list of build phases, where in a build phase represents a stage in the lifecycle.

生命周期中的每个都被定义为不同的构建阶段的列表,也就是在构建阶段代表一个生命周期中的时段。

For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):

例如:默认的生命周期有下列的构建阶段(对于一个完整的构建阶段的列表,涉及到的生命周期参考如下):

validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
摘自http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

validate :验证项目是正确的以及所有必须信息是可用的;

compile:编译项目源代码;

test:用适当的单元测试框架测试编译过的源代码;

package:取到编译过的代码并用各自的分发格式打包;

integration-test:处理和发布集成测试运行环境必须的一些包;

verify:运行任何能使包有效和符合质量标准的审核;

install:安装这些包放入得到本地库,能使另外的本地的有所依赖项目使用;

deploy:在整合或者发布环境下执行,复制最终的包到远程库使与其他的开发者和项目共享。


3、POM的介绍(Introduction to the POM)
摘自http://maven.apache.org/guides/introduction/introduction-to-the-pom.html


--------------------------------------------------------------------------------

1)什么是POM(What is a POM)
A Project Object Model or POM is the fundamental unit of work in Maven.It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects

一个项目的对象模型(POM)是用Maven工作的基础单元。这个是XML文件,它包含关于项目和配置的具体信息,这些信息可以被Maven用了构建项目。对于大多数的项目它包含缺省的值。

2)父类POM(Super POM)
The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects

父类POM是Maven的缺省POM。所有的POM都是继承父类POM,除非有特殊的设置,也就是说在父类POM中的指明的配置是要被我们的为项目创建的POM继承的。

3)最小POM(Minimal POM )
The minimum requirement for a POM are the following:

project root
modelVersion - should be set to 4.0.0
groupId - the id of the project's group.
artifactId - the id of the artifact (project)
version - the version of the artifact under the specified group
project root :文件根节点;

modelVersion:对象模型的版本;

groupId:组织的ID;

artifactId:项目的ID;

version :产品版本号。

4)项目继承(Project Inheritance)
待续


4、构建Profiles介绍(Introduction to Build Profiles )
摘自http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Maven 2.0 goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inhertiance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.

Maven2.0正竭尽全力使构建变得轻便。此外,这意味允许包含在POM构建配置能避免所有的文件系统的相关(以继承,依赖以及另外的角度),

以及更倾向于存储元数据本地的库变的有可能。

However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.

然而,有些便携性是完全不可能。在肯定无疑的条件下,插件有可能需要去被用本地的文件系统的路径去配置。在其他环境下,一些微小的不同依赖设置时必需的,并且这些项目组件名称可能被稍微的改动。并且在其他情况下,你可能甚至需要去包含在构建生命周期中一整套依赖于构建环境的插件。

To address these circumstances, Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.

为了解决这些情况,Maven2.0引入了构建profile的概念。Profiles 被指派用元素的子设置能在POM中自己访问(一个格外的一部分),并且在任何能被各式各样的方法触发。在构建的时候他们修改了POM,并且意味着被用来在互补设置,为一个目标环境(比如:在开发,测试,产品环境下应用服务的根目录)合集提供等同但不一样的参数。也即,profiles 能很容易引导来自于你团队的不同成员不同的构建结果。然而,适当的利用,profiles 依然能被用于保留项目适应性。也就最小的利用maven,能够允许用户去用不同的参数或者配置创建另一个POM的构建,这个构建能从只要用一个POM运行开始更加可具维护性。

不同类型profile是什么,每个在哪里定义(What are the different types of profile? Where is each defined ?)
Per Project -Defined in the POM itself (pom.xml).
Per User - Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
Global - Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
Profile descriptor - a descriptor located in project basedir (profiles.xml)
Per Project - 定义在pom.xml中
Per User - 定义在Maven-settings中 (%USER_HOME%/.m2/settings.xml).
Global - 定义在global maven-settings中 (%M2_HOME%/conf/settings.xml).
Profile descriptor - 直接放到工程basedir下的profiles.xml中
5、仓库的介绍(Introduction to Repositories)
1)Artifact 仓库(Artifact Repositories)
A repository in Maven is used to hold build artifacts and dependencies of varying types.

一种Maven被用创建各式各样的artifacts 和依赖仓库

There are strictly only two types of repositories: local and remote. The local repository refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released.

严格意思上只有两个类型的仓库:本地和远程。本地的仓库指的是一个你自己安装备份,也即远程下载的缓存,也包含临时的你还未发布的构建artifacts

2)正在用的仓库(Using Repositories)
In general, you should not need to do anything with the local repository on a regular basis, except clean it out if you are short on disk space (or erase it completely if you are willing to download everything again).

大体上,你不需要去以基础的规则用本地的库做任何事情,除非如果你想减小磁盘空间而清楚它。(或者如果你再一次将所有的下载来而完全的擦掉它)

For the remote repositories, they are used for both downloading and uploading (if you have the permission to do so).

对于远程仓库,他们被用来既用来下载也被用上传(如果你有权限这么做)。


6、依赖机制介绍(Introduction to the Dependency Mechanism )
摘自:http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Dependency management is one of the features of Maven that is best known to users and is one of the areas where Maven excels. There is not much difficulty in managing dependencies for a single a project, but when you start getting into dealing with multi-module projects and applications that consist of tens or hundreds of modules this is where Maven can help you a great deal in maintaining a high degree of control and stability.

依赖管理是一个最为被人知道的Maven的特征,是一个Maven卓越的应用领域。在一个单独的项目管理依赖中没有多少难度,但是当你开始在处理多模型的那些包含成十上百模型的项目和应用时候,Maven能帮助你很多在维护高控制和稳定性方面的处理。

1)依赖范围(Dependency Scope)
here are 6 scopes available:
compile
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
provided
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
runtime
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
test
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
system
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
import (only available in Maven 2.0.9 or later)
This scope is only used on a dependency of type pom in the <dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

7、标准目录布局介绍(Introduction to the Standard Directory Layout)

--------------------------------------------------------------------------------

摘自http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.

有一个共同的目录布局将使我们马上熟悉一个Maven项目,在另一个Maven项目中就会感觉很类似了。这样的好处是很快从直观上适应类似的站点。

The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.

接下去的一段目录布局文档是Maven期待的,并且这个目录布局也被Maven创建的。如果你不能通过项目描述把这些设置的文件目录覆盖,那么,请尽可能试着确认这些结构。

src/main/java Application/Library sources java文件存放路径
src/main/resources Application/Library resources 资源文件存放路径
src/main/filters Resource filter files 过滤文件存放路径
src/main/assembly Assembly descriptors 描述文件存放路径
src/main/config Configuration files 配置文件存放路径
src/main/webapp Web application sources Web应用存放路径
src/test/java Test sources 测试文件存放路径
src/test/resources Test resources 测试资源问存放路径
src/test/filters Test resource filter files 过滤文件存放路径
src/site Site 站点打包文件存放路径
LICENSE.txt Project's license 项目许可证
README.txt Project's readme 项目说明

At the top level files descriptive of the project: a pom.xml file (and any properties, maven.xml or build.xml if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: README.txt, LICENSE.txt, etc.

在上面的项目文件描述文件中:就是 pom.xml 文件(或者任何的属性文件,maven.xml或者如果用Ant 那就是build.xml )。另外,还是有文本文件意味着用户能立即阅读以便接受这些源代码:就是README.txt, LICENSE.txt,等等。

8、常用命令
1)创建Mave项目(make Maven project)
mvn archetype:create \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DgroupId=com.mycompany.app \
-DartifactId=my-app

实例介绍

2)编译应用代码(compile application sources)
mvn compile

3)编译测试文件以及运行单元测试文件(compile test sources and run unit tests)
mvn test

4)创建JAR包并且安装在本地的仓库中( create a JAR and install it in local repository)
mvn package

5)在本地 Repository 中安装 jar(install the artifact you've generated the JAR file)
mvn install

6)刷新目标文件
remove the target directory with all the build data before starting so that it is fresh

在开始构建前移除构建数据的目标文件,以目标文件能够刷新

mvn clean

实例(MavenDemo)

--------------------------------------------------------------------------------

1、工程建立
使用Maven的archetype插件来创建工程: D:\mavendemo>mvn archetype:create -DgroupId=demo.mvn -DartifactId=mavedemo01

说明: mvn archetype:create :创建 Maven 项目 , -DgroupId:组标记 既src的路径 , DartifactId:项目名称,既项目主目录的名称。

目录结构:mavedemo01
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- demo
| `-- mvn
| `-- App.java
`-- test
`-- java

`-- demo
`-- mvn
`-- AppTest.java


POM.XML

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>demo.mvn</groupId>
<artifactId>mavedemo01</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>mavedemo01</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>


说明:

<project>:根节点

<modelversion>:POM版本

<groupid>:组织的ID

<artifactId>:项目ID

<pacekaging>:打包扩展名

<version>:版本

<name>:项目名

<url>:站点

<description>:项目描述

<scope>:作用域

<dependencies>:依赖组

<dependency>:依赖
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值