由MAVEN入手浅谈项目构建与管理

crespo09 发表于 2017-3-1 11:23:32

Prologue . 前言
　　　　第一次写博客，希望爱学习的小伙伴们喜欢。
　　　　JAVA软件开发领域很喜欢一个名词，叫做"约定大于配置 "。我在此当然约法三章。
　　

　　　　　　写博客优先级很低。希望借此激发学习动力。

　　　　　　参考权威和官方文档，独立思考，希望错误的观点被指正。

　　　　　　对过去一段时间工作中的技术预研的思考总结。
　　
　　　　准备工作之外花费了很多时间。作为前端小白接触样式并适应博客园。选择了MAVEN为切入点，因为工作中吃饭睡觉打豆豆都是用MAVEN。希望能分享一些基础的观念，并且送给自己一份毕业周年的礼物。搞起~！@
　　

Chapter one . Article Purpose
　　　　目的：学会使用工具帮助开发者做繁琐的事情。
　　　　内容：本文由maven入手，浅谈我在工作中对于 JAVA项目构建与管理的理解。
　　　　特色：在maven基础框架理解中提出的观点与质疑。
　　　　侧重点：maven的学习理解。
　　　　O(∩_∩)O
　　

Chapter two . Introduce Maven

what is Maven

official interpretation
　　英标：[`meivin]
　　英译：专家
　　释义：Apache 指出Maven 是一个项目管理工具。它的内容有：

　　内容

　　英文

　　项目对象模型

　　Project Object Model

　　标准集合

　　Standard Collection

　　项目生命周期和阶段

　　Project Lifecycle and Phase

　　依赖管理系统

　　Dependency Management System

　　插件和目标

　　Plugin and Goal

　　仓库

　　Repositories

　　部分内容会在下文中讲述。

personal understand

　　　　简单说maven还真他喵的是款项目管理工具。

　　　　他可以帮助我们：

　　　　　　整理复杂的jar依赖层次依赖。
　　　　　　处理项目父子关系。
　　　　　　了解项目构建结构和周期。
　　　　　　集成各种插件。
　　　　　　持续集成工具。

　　　　如果我们简读过一些开源框架，会发现框架（尤其是apache 项目）很重要的编程观点：
　　　　　　基于XML编程

　　　　　　约定大于配置

　　　　Maven是基于pom.xml文件的管理工具。它解析用户配置的pom文件，将其中的节点解读成一个个构件。
　　　　（插件、依赖、输出都可以是一个构件）。
　　　　一个MAVEN项目的结构的基本约定如下所示：

　　路径

　　描述

　　src/main/java/

　　java源代码包，编译后通过getClass()

　　src/main/resource/

　　配置文件资源包，编译后通过getResource()读取

　　src/test/java/

　　test源码包

　　src/test/resource/

　　对应资源包

　　target/

　　compile、site、report目标路径

　　pom.xml

　　POM文件

　　　　备注：你可以根据resource插件自己定义你需要的目录结构。

preparatory knowledge

　　　　下面我们可能要理解一些基本概念的简单栗子。

[*]依赖 dependency

　　　　我们举个例子，你有一座葡萄酒工厂，（公司。）

　　　　新疆的红葡萄生产红葡萄酒。加州的白葡萄生产白葡萄酒。（项目。）

　　　　是的，你酿制葡萄酒使用了许多步骤（依赖。）

　　　　这么多步骤组成了一个秘方。（依赖树。）

　　　　开心的是，秘方还可以任意组合搭配，你一定很富有。

　　　　每个员工都不会愿意酿制葡萄酒时自己去仓库取一堆葡萄和酒精。（一组jar包。）

　　　　要是有差别味道会很差。（jdk版本的差异都会对开发造成影响。）

　　　　这时候你想要拥有一条装配线。（maven工具）

　　　　生产葡萄酒的员工们仅仅需要一份秘方。（pom.xml文件）

　　　　派送的师傅就会把葡萄和原料送到员工手上。（仓库Repositories。）

　　　　　（别闹，我在激发写作兴趣=。=）

　　
　　　　　在pom.xml中声明一个依赖节点dependency。它大概长这个样子。

1 <properties>
2
3 <junit.version>3.8.2</junit.version>
4
5 </properties>
6
7 <dependencys>
8
9 <dependency>
10
11 <groupId>junit</groupId>
12
13 <artifactId>junit</artifactId>
14
15 <version>${junit.version}</version>
16
17 <scope>test</scope>
18
19 </dependency>
20
21 </dependencys>
View Code　　　　同时，依赖具有传递性。

[*]坐标 Coordinates

　　　　每一个依赖都是唯一的项目坐标。

　　　　上述节点定义

　　groupId

　　artifactId

　　version

　　组织

　　项目

　　版本

　　　　这是全世界唯一的值，用来描述一个JAR包。我认为这是maven的逻辑归档。

　　　　备注：这个唯一有偏颇，事实上唯一的是：

　　　　groupId.artifactId-major_version.minor_version.incremental_version-classifier.package

　　
　　　　根据坐标，你可以找到你想要的任何jar包。

mvn clean install -Dmaven.test.skip=true;
View Code　　　　将你配置在pom.xml文件中的依赖从远程仓库下载到本机仓库，实现自动依赖。

[*]apache maven安装目录

　　路径

　　描述

　　bin/

　　maven运行脚本

　　boot/

　　类装载器

　　conf/

　　全局变量settings.xml文件 .part7

　　lib/

　　自身核心jar包

　　LICENSE

　　Apache软件许可证

　　NOTICE

　　通知权限

　　README.txt

　　安装指令

有了基本概念，就一起走入maven世界吧。O(∩_∩)O
why me maven

　　虽然maven功能强大，但是个人用maven做下述事情：

　　　　管理第三方jar包版本和依赖。　　　　　　配置远程仓库nexus repository。
　　　　　　使用插件做项目构建。
　　　　　　项目代码质量检测。（PMD, findbugs, checkstyle你懂的。）
　　　　　　方便集成持续集成工具。
　　　　　　管理分布式应用多项目依赖关系。　　

　　其他的不做解释。
how to maven

install maven : http://maven.apache.org
　　　　Maven安装的详细步骤我不做说明。

　　　　安装JAVA 　　　　　　配置JAVA环境变量
　　　　　　安装MAVEN
　　　　　　配置MAVEN环境变量

　　备注：我本机桌面不在C盘，所以不配置本机仓库路径。

mvn –v;
mvn help:system;
View Code

　　　　All right，这时候本机上就会有一个几M小的可怜的maven。嘿，别高兴太早，它只是maven工程的最小集合。每当你使用一个命令（每个命令都是maven插件plugin的一个目标goal）。maven根据pom.xml把依赖树中缺失的依赖包含的jar文件下载，我们称这个过程为安装install。

touch maven in CMD

　　　　请务必像我一样使用前先熟悉下基本操作。
　　　　shirt + right click open CMD anywhere:

mvn -v; //查看mvn版本
mvn help:system; //查看系统变量
mvn archetype:generate -DgroupId=sapphire.webtest
-DartifactId=firstweb -DarchetypeArtifactId=maven-archetype-webapp -Dversion=1.0;
//创建一个maven we b原型项目firstweb，其中让你输入一个数字，表示发行快照SNAPSHOT版本
cd firstweb;
mvn eclipse:eclipse; //将项目转换为eclipse web项目方便导入。
mvn clean install -U -e -B;
//将项目target文件清空并重新编译安装(参数分别表示强制检出SNAPSHOT，打印失败日志，批处理)
mvn help:effective-pom; //输出有效pom文件，这可以帮助你了解superpom结构，或者优化pom依赖。
View Code　　是的，单单上面的步骤，你就要下载好久。

maven projects manage　　
　　　　maven管理多级项目通过在pom.xml中配置父节点和子节点。
　　　　　　父工程中：

<modules>
<module>simple-son1</module>
<module>simple-son2</module>
</modules>
View Code

　　　　　　子工程中

<parent>
<groupId>…</groupId>
<artifactId>simple-parent1</artifactId>
<version>1.0</version>
</parent>

　　　　maven还支持引用依赖实现继承.

<project>
<dependencies>
<dependency>
<groupId>…</groupId>
<artifactId> simple-parent1</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
View Code

　　　　这里比普通的依赖多了一个type：

　　类型

　　作用

　　Jar

　　产生一个JAR 文件，子工程不能继承

　　War

　　产生一个web 应用，子工程不能继承

　　Pom

　　产生一个父工程

Chapter three . Build a Project

identification
　　　　项目构建：翻阅了许多资料，也没有发现对于构建准确的解释。（一定是我太蠢T. T）

personal understand

　　　　构建是一个生成输出的过程，在项目中。构建做以下事情。
　　　　　　代码编译 source code

　　　　　　依赖整理 order dependency

　　　　　　发布文档 release and report

　　　　　　变更记录 change log

　　　　　　生成目录 publish structure

　　　　举个栗子：有个宝贝，你将蔬菜水果沙拉生肉牛奶统统丢进去，自动做好香甜可口的饭菜。

　　　　项目构建就是这么个过程，哪怕宝贝是你的爪子=。=，将代码构建成可执行软件并发布。

question：

　　　　什么是可执行软件？应用目录如何在服务器上工作？

　　　　一个应用的目录概念如下表：
　　　　

执行环境：eclipse Maven Tomcat CentOS　　

eclipse web项目
maven工程项目

　　src
　　config

　　webContent

　　src
　　resource

　　webapp

Tomcat是基于web.xml配置的服务器，当你使用eclipse tomcat插件时，eclipse自动编译JAVA文件，并根据项目结构构建出目录，放到tomcat的webapp下。tomcat我日后会抽时间单独总结。O(∩_∩)O

project structure

　　　　我们引申一个概念：项目结构。我比较喜欢酱紫描述一个普通的JAVA应用结构概念。

　　目录

　　是否必要

　　描述

　　static/

　　否，一般都有静态资源的概念，除非你有静态资源服务器。

　　静态资源。

　　META-INF/

　　否

　　描述信息。

　　WEB-INF/

　　是

　　WEB信息。

　　　　然后再看看WEB-INF/下的内容。

　　目录

　　是否必要

　　描述

　　classes/

　　是

　　应用程序编译好的class文件

　　lib/

　　是

　　第三方依赖jar包。（本来觉得不必要，不过一想你不要servlet包玩毛web啊=。=）

　　tags/

　　否

　　自定义标签

　　src/

　　否

　　源码

　　config/

　　是

　　配置文件，如数据库连接、可配变量等。

　　views/

　　是

　　Web程序总需要有视图层吧。jsp freemaker velocity随你啦。

　　web.xml

　　是

　　Web.xml文件

　　　　当你将这样一个目录结构放在tomcat的webapp文件夹下，tomcat寻找到web.xml读取相关配置文件，
　　　　读取配置文件，加载class文件和jar包class文件，启动并运行。~

　　
　　　　备注：即使你的项目结构不是这样的，你可以通过配置pom.xml达到目的：

<build>
<Directory>target</directory>
<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test</testSourceDirectory>
<outputDirectory>bin</outputDirectory>
</build>
View Code

experience

　　　　然并卵，如果你想将应用放在linux服务器上eclipse可没什么用。公司可不会给你视图工具操作服务器，你需要自己去构建工程。处于创业型公司，我对构建项目的概念真的是从无到有，虽然现在也没有高明到哪里去。下面我会介绍一年来在封闭开发，加班开发，日常开发中（夭折啦）对构建项目的失败经验。

[*]石器时代

　　　　使用Beyond Compare软件直接创建目录结构，当项目简单时我们确实用过这种蛮夷的方式构建项目。使用7z压缩软件将目录文件压缩成tar.gz包再压缩成zip文件用ftp工具上传到服务器的tomcat/webapp里。命令行连接服务器工具至今我还使用putty.

Ls ll; //查看可执行权限，没权限，我做过这种蠢事。T. T
ps –ef|grep ${tomcatname}
kill -9 ${pid} //shutdown tomcat只会关闭tomcat守护线程，我做过这种蠢事。T. T
cd ${tomcat/webapp}
unzip ${appname}.zip; //解压
tar -zxvf ${appname}.tar.gz; //解压
vi ${properties and xml} //修改配置文件，请确认端口唯一，我做过这种蠢事。T. T
cd ${tomcat/logs}
rm –rf *; //如果你删除logs目录tomcat无法正常启动的，我做过这种蠢事。T. T
cd ${tomcat/bin}
./start.sh //不能有空格，我做过这种蠢事。T. T
cd ${tomcat/logs}
tail –f catalina.out //查看项目启动有木有报错，常用这个逼格命令，外行人看起来很酷。
View Code

[*]
青铜时代
　　　　使用ant工具打包。配置build.xml
　　　　这段时间的经验让我感受到一些基本概念。

　　　　xml编程　　　　　　target概念
　　　　　　build生命周期
　　　　其中最重要一段：

<target name="package" depends="prepare,build.jars,build.conf,generate-tar-gz,generate-zip">
</target>
View Code

　　弃用的主要原因是我是一个二把刀，每次添加一个配置文件都需要修改build.xml脚本中build.conf过程。
　　而且会也没有更好的方式处理项目间依赖关系。随着项目增重，我放弃了这一方式。

[*]
铁器时代
　　Eclipse导出war包打包。
　　war包是tomcat可读应用包，eclipse支持导出一个web项目的war包。tomcat会感应webapp下war包的修改并热部署。war包会先构建一个类似上面描述的项目目录，然后tomcat解析运行.热部署意味着：tomcat启动时如果删除war包会导致构建目录也删掉。T. T

[*]
蒸汽时代
　　　　　利用maven插件打包。
　　随着项目增多，体系多级依赖，甚至父工程间也存在依赖关系。使用maven插件。

　　插件名称

　　描述

　　备注

　　maven-antrun-plugin

　　Ant的maven插件

　　别和我提ant。

　　maven-assembly-plugin

　　打包工具

　　Maven推荐的打包工具，可以打成tar.gz包等多种类型。

　　maven-war-plugin

　　打包工具

　　将web项目打成war包，包含项目重命名，输出定向，过滤文件，归档等功能。

　　maven-source-plugin

　　打包辅助工具

　　帮助打包你的源码

maven打包工具多样，各类具体配置网上都容易查到。最好的学习网站还是官网。

在我日常构建过程中，单纯在编译时期打包并无法满足需求。　　为了说明这个问题这里引用maven一个概念：
　　　　maven属于JAR包依赖而非工程依赖，这意味着执行子项目前，你需要把父工程安装完毕。这意味着，如果你的父项目依赖其他核心组件，例如技术中间件，业务中间件，业务接口等。你需要先deploy到服务器上，然后再使用项目构建，把发布到仓库里的其他项目安装下来。=。= 我说的很糊涂，请忘细。

[*]
信息时代
　　　　持续集成。Continuous integration。持续集成是敏捷开发的阿哈利姆的神杖。^_^
　　　　最近在网络上看了许多jenkins和hudson的使用案例，觉得很棒，它在本文中不是浅谈重点，所以有机会会有一个单独的总结意愿。这里只贴个头~~~

　　持续集成Continuous integration

　　提出

　　针对复杂度高的项目提出"早集成，常集成，频繁集成"来帮助项目在早期发现项目风险和质量问题

　　作用

　　减少风险

　　减少重复过程

　　任何时间、任何地点生成可部署的软件

　　增强项目的可见性

　　建立团队对开发产品的信心

　　概念

　　持续集成是一种软件开发实践，对于提高软件开发效率并保障软件开发质量提供了理论基础。持续集成是一种软件开发实践，对于提高软件开发效率并保障软件开发质量提供了理论基础。

Chapter four . Lifecycle and Phase

question
　　　　相信各位和我一样在初学maven时最郁闷的事是：有病啊为啥命令非要这么复杂。
　　mvn clean compile site
　　笑一笑，这里就涉及到maven命令的生命周期和过程。

生命周期 Lifecycle

identification
　　　　生命周期是对所有的构建过程的进行抽象和统一。
　　　　因为操作人员构建方式千变万化，所有公司的构建模式都大致相同。
　　　　我曾翻遍maven核心代码寻找这个生命周期阶段，直到我在官方介绍上看到这么一句话：
　　 default lifecycle is defined without any associated. Bindings are defined separately for every packaging.
　　链接：http://maven.apache.org/ref/3.0.4/maven-core/lifecycles.html
　　然而，机智的我在maven-core.jar和maven-plugins.jar了解到这一内容。
　　　　Maven包含三种不同且独立生命周期：

　　生命周期

　　描述

　　clean

　　清理项目，一般用来清除target编译目录。

　　default

　　构建项目，默认生命周期。

　　site

　　建立项目站点。

　　　　网上针对该版块介绍很多,对于clean 和 site lifecycle略。
　　　　这里介绍最常用default lifecycle默认生命周期，请往下看。

阶段 Phase
　　　　机智的我同时在maven插件开发中发现这样一个注解，描述了生命周期各个阶段
　　　　org.apache.maven.plugins.annotations.lifecycleParse

　　过程

　　描述

　　validate

　　验证项目是否正确，以及所有为了完整构建必要的信息是否可用。

　　generate-sources

　　生成所有需要包含在编译过程中的源代码

　　process-sources

　　处理源代码，比如过滤一些值

　　generate-resources

　　生成所有需要包含在打包过程中的资源文件

　　process-resources

　　复制并处理资源文件至目标目录，准备打包

　　compile

　　编译项目的源代码

　　process-classes

　　后处理编译生成的文件，例如对Java 类进行字节码增强（bytecode enhancement）

　　generate-test-sources

　　生成所有包含在测试编译过程中的测试源码

　　process-test-sources

　　处理测试源码，比如过滤一些值

　　generate-test-resources

　　生成测试需要的资源文件

　　process-test-resources

　　复制并处理测试资源文件至测试目标目录

　　test-compile

　　编译测试源码至测试目标目录

　　test

　　使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布

　　prepare-package

　　在真正打包前，执行准备打包必要的操作。这通常会产生一个包的展开的处理过的版本。

　　package

　　将编译好的代码打包成可分发的格式，如JAR，WAR，或者EAR

　　pre-integration-test

　　执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境

　　integration-test

　　如果有必要的话，处理包并发布至集成测试可以运行的环境

　　post-integration-test

　　执行一些在集成测试运行之后需要的动作。如清理集成测试环境。

　　verify

　　执行所有检查，验证包是有效的，符合质量规范

　　install

　　安装包至本地仓库，以备本地的其它项目作为依赖使用

　　deploy

　　复制最终的包至远程仓库，共享给其它开发人员和项目（通常和一次正式的发布相关）

　　你没有看错，上面这个表完全是在凑！字！数！
　　其中比较重要的有：（插件列是maven绑定在默认生命周期中的各个过程阶段插件。）

　　过程

　　插件

　　作用

　　compile

　　compiler

　　编译src/main/java源代码和其他配置的资源目录，到输出目录。

　　resource

　　resources

　　复制src/main/resource资源和其它配置的测试资源目录，到测试输出目录。

　　test

　　surefire

　　运行所有的测试并且创建那些捕捉详细测试结果的输出文件。

　　package

　　jar

　　把输出目录打包成JAR 文件。

　　install

　　install

　　将项目输出或某指定的文件加入到本机库

　　deploy

　　deploy

　　将项目输出或某指定的文件加入到仓库中。

　　maven源码将lifecycle中每一个phase放在一个LinkedList里，而在此phase运行命令时，　　
　　　　会使LinkedList前面的节点被链式调用。　
　　　　比如：
　　　　你可以编译。
　　 mvn clean compile;

　　　　也可以直接安装，会同样执行编译阶段上的所有插件。（该命令跳过测试阶段）
　　 mvn clean install –Dmaven.test.skip=true;
　　　　所以你要知道的是：

[*]当你使用一条maven命令，实质上，它不是maven的bin命令，它常常是maven默认的插件中的默认目标goal当goal执行时，触发LinkedList里以前的节点上配置的插件全部执行。

[*]每个阶段仅仅是阶段而已，如果没有在pom.xml中安装插件，阶段只执行默认插件。

Chapter five . Scope and Archetype
　　这两个问题不深入探讨。

使用范围 Scope

qustion
　　　　我已经解释了项目中每一个依赖在maven管理中就是一个depandency节点。Maven里如何控制节点范围呢。

<dependency>
<groupId>i.need.wlan</groupId>
<artifactId>i.need.wlan</artifactId>
<version>1.0.0</version>
<scope>test</scope>
</dependency>
View Code

　　　　请原谅我不能举出更生动的例子，我断网了。还好有存货。枚举scope。

　　范围

　　描述

　　Compile（默认）

　　编译范围。

　　Provided

　　已提供范围。当JDK 或者一个容器已提供该依赖之后才使用。

　　Runtime

　　运行时范围。依赖在运行和测试系统的时候需要，但在编译的时候不需要。

　　Test

　　测试范围。在测试编译和测试运行阶段可用

　　System

　　已提供范围。显式的提供一个对于本地系统中JAR 文件的路径

骨架原型 Archetype

nature
　　　　是maven工程自己的项目结构。
　　　　常用的原型有：

　　Artifact

　　Group

　　Description

　　maven-archetype-j2ee-simple

　　org.apache.maven.archetypes

　　A simple J2EE Java application

　　maven-archetype-quickstart

　　org.apache.maven.archetypes

　　maven-archetype-simple

　　org.apache.maven.archetypes

　　maven-archetype-webapp

　　org.apache.maven.archetypes

　　A simple Java web application

　　　当你不使用命令行创建maven项目时，你并不需要考虑骨架原型。
　　　使用eclipse创建项目时，你需要new maven project/module，选择archetype，创建一个原始maven工程。
　　　然后通过添加resource folder和eclipse project Facets转换功能，将新建的maven工程转变为eclipse工程。

Chapter six . Plugin and goals

identification
　　　　Maven的核心包如此之小是因为它仅仅定义了抽象的生命周期，和开发API。具体的任务是交由插件完成的，插件以"独立"的构建形式存在。
　　　　比如：

[*]maven-dependency-plugin插件
　　　　分析项目依赖，找到重复的依赖，列出项目的依赖树。

[*]maven-source-plugin插件
　　　　这个可能是最核心的插件了，因为它负责下载maven中央库中的依赖。

different

　　　　插件和普通依赖在pom.xml中的区别。

　　依赖

　　插件

　　package

　　Pom    父工程

　　package

　　maven-plugin

　　Jar       子普通工程

　　War    子web工程

　　impl

　　(nothing)

　　impl

　　org.apache.maven.plugin.Mojo

　　在设计插件时，你需要声明多个任务goal。每个goal实现不同的功能。现在你可以通过 mvn plugin：goal 调用mvn命令了。

mvn clean:clean
mvn dependency:tree
mvn help:system
mvn idea:idea
mvn jetty:run
mvn hibernate3:hbm2ddl
View Code

　　它们就好像ant中target一样。
　　插件地址： http://maven.apache.org/plugins/index.html

Chapter seven . setting.xml and nexus

配置文件 Setting.xml
　　　　Maven工作文件为pom.xml，而本身默认配置文件是setting.xml。
　　　　在setting.xml中你可以配置：

　　说明

　　配置

　　Maven依赖管理路径，最终系统下载下来的依赖都会放进去。

　　<localRepository> usr/local/maven </localRepository>

　　权限设置，控制与远程私服库依赖的关联，能否deploy

　　<server>
　　 <id>snapshot-distributed</id>
　　 <username>…</username>
　　 <password>…</password>
　　</server>

　　　　这里给出一个setting.xml文件的详细配置解读，这样很蠢，但是能说明问题。
　　　　忘了在哪里拷贝的。

1 <?xml version="1.0" encoding="UTF-8"?>
2 <settings xmlns=http://maven.apache.org/POM/4.0.0
3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
5
6<localRepository>usr/local/maven</localRepository>
7
8<interactiveMode>true</interactiveMode>
9
10<usePluginRegistry>false</usePluginRegistry>
11
12<offline>false</offline>
13
14<pluginGroups>
15 
16 <pluginGroup>org.codehaus.mojo</pluginGroup>
17</pluginGroups>
18
19<proxies>
20 
21 <proxy>
22 
23 <id>myproxy</id>
24 
25 <active>true</active>
26 
27 <protocol>http</protocol>
28 
29 <host>proxy.somewhere.com</host>
30 
31 <port>8080</port>
32 
33 <username>proxyuser</username>
34 
35 <password>somepassword</password>
36 
37 <nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts>
38 </proxy>
39</proxies>
40
41<servers>
42 
43 <server>
44 
45 <id>server001</id>
46 
47 <username>my_login</username>
48 
49 <password>my_password</password>
50 
51 <privateKey>${usr.home}/.ssh/id_dsa</privateKey>
52 
53 <passphrase>some_passphrase</passphrase>
54 
55 <filePermissions>664</filePermissions>
56 
57 <directoryPermissions>775</directoryPermissions>
58 
59 <configuration></configuration>
60 </server>
61</servers>
62
63<mirrors>
64 
65 <mirror>
66 
67 <id>planetmirror.com</id>
68 
69 <name>PlanetMirror Australia</name>
70 
71 <url>http://downloads.planetmirror.com/pub/maven2</url>
72 
73 <mirrorOf>central</mirrorOf>
74 </mirror>
75</mirrors>
76
77<profiles>
78 
79 <profile>
80 
81 <id>test</id>
82 
83 <activation>
84 
85 <activeByDefault>false</activeByDefault>
86 
87 <jdk>1.5</jdk>
88 
89 <os>
90    
91    <name>Windows XP</name>
92    
93    <family>Windows</family>
94    
95    <arch>x86</arch>
96    
97    <version>5.1.2600</version>
98 </os>
99 
100 <property>
101    
102    <name>mavenVersion</name>
103    
104    <value>2.0.3</value>
105 </property>
106 
107 <file>
108    
109    <exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</exists>
110    
111 <missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</missing>
112 </file>
113 </activation>
114 
121 <properties>
122 <user.install>/ebs1/build-machine/usr/local/hudson/hudson-home/jobs/maven-guide-</user.install>
123 </properties>
124 
125 <repositories>
126 
127 <repository>
128    
129    <id>codehausSnapshots</id>
130    
131    <name>Codehaus Snapshots</name>
132    
133    <releases>
134    
135    <enabled>false</enabled>
136    
137    <updatePolicy>always</updatePolicy>
138    
139    <checksumPolicy>warn</checksumPolicy>
140    </releases>
141    
142    <snapshots>
143    <enabled/><updatePolicy/><checksumPolicy/>
144    </snapshots>
145    
146    <url>http://snapshots.maven.codehaus.org/maven2</url>
147    
148    <layout>default</layout>
149 </repository>
150 </repositories>
151 
152 <pluginRepositories>
153 
154       <pluginRepository>
155    <releases>
156    <enabled/><updatePolicy/><checksumPolicy/>
157    </releases>
158    <snapshots>
159    <enabled/><updatePolicy/><checksumPolicy/>
160    </snapshots>
161    <id/><name/><url/><layout/>
162       </pluginRepository>
163       </pluginRepositories>
164       
166 <activeProfiles>
167 
168 <activeProfile>env-test</activeProfile>
169 </activeProfiles>
170 </profile>
171</profiles>
172 </settings>
View Code

Nexus服务器

question
　　　　你一定觉得喵的玩了这么久，居然还是玩单机！
　　这里需要提出一个概念：仓库repository
　　maven的仓库包含：

　　本地仓库：你本机的仓库，就是你在setting.xml配置的localRepository

　　远程仓库：

　　私服：maven提供的nexus服务器

　　中央仓库：maven公共库，所有的插件、依赖都在这里

　　然后请不要取笑我的草率=。=我没网。
　　
　　nexus私服是建立在local repo和central repo间的构件管理服务器。他的机制是代理一些广域网上的远程仓库，供局域网内的Maven用户使用。上图画的并不严谨，因为宿主仓库nexus和中央仓库（central repo是最大的远程仓库）存在并列关系，只是优先级不同。当多台用户连接一个远程仓库时，nexus仓库只需要在外网的中央仓库下载一次依赖，所有的用户都会在nexus仓库中检测到依赖直接使用。

　　详细如何安装nexus服务器请自己查阅。

　　　　　　　　win    :　　 http://www.cnblogs.com/dingyingsi/p/3687077.html

　　　　　　　　linux    :　　 http://www.cnblogs.com/leefreeman/archive/2013/04/03/2998315.html 　　
　　　　　在本小节结束的最后，根据我的肤浅经验，我不得不提出一条忠告：

　　　　　　　如果你修改了第三方依赖源码并上传到私服上，请同时上传源码包。

　　　　　源码包和依赖包唯一的区别就是：

　　依赖包名称

　　源码包名称

　　example.jar

　　example-source.jar

Chapter eight. Super Pom

identification

question
　　　　说了半天，什么是pom.xml？

　　　　对于maven pom.xml最终会被解析为项目对象模型(Project Object Model)。Maven通过pom文件管理项目依赖。使用者创建的maven工程pom.xml文件隐式继承super.pom你可以在maven-model-builder.jar找到。它声明了中央仓库的位置，约定了项目结构，引入了一些打包和编译的插件.你可以参考：http://maven.apache.org/ref/3-LATEST/maven-model-builder/super-pom.html
　　　它解析读取xml节点，最终通过LinkedHashSet实现每个依赖DataModel的坐标，并构造一个树依赖通过LinkedHashMap管理。下载依赖时，会得到LinkedHashMap中的依赖树依次下载。具体的pom配置我不详细描述，你可以参考：blog.csdn.net/yaerfeng/article/details/26448417

Chapter nine . optimalize Conflict
　　　Maven中最痛苦的事情就是依赖的优化与冲突，所以这里单独拉出一个章节说明。

　　　这种现象的根本原因是由于依赖的复杂度：

[*]版本兼容性问题。

[*]间接依赖，多重依赖问题。

　　　　　举个栗子：

　　　　小明和小毛，小淙是朋友。

　　　　小淙和小涛是朋友。

　　　　小涛和小毛见面就打架。

　　　　问题是他们四个能不能长久一起愉快的玩耍？

　　　　你一定会说，跳皮筋小涛，小明，小淙玩。打沙包小明，小毛，小淙玩。

　　　　　呵呵，单纯。Maven当然想到了这一点：scope范围界定运行时依赖。

　　　　　然而运行时所依赖包最终是要安装到生产环境的，这部分工作 Maven 并不能完成。

　　

　　　　　怎么办呢，这时候你就需要改源码，或者google之……

　　

　　　　你可以通过一个命令查询该maven项目有效的pom当前依赖。

mvn help:effective-pom;
View Code
Chapter final . never be end
　　　　这篇文章并没有什么真正的技术含量，在工作中算是日经帖。希望这是我接触开源技术社区的第一步吧。学习maven过程对我来说是一个漫长的过程，直到现在为止我也只接触了八个月。这篇杂谈着实没有什么逻辑。
　　　　希望给更多初学者启发，也希望带给高端玩家新的学习乐趣。
　　　　这篇博客耗时20小时，又花了数个小时调整样式，都是这周内午夜11点到凌晨2点完成的。写作过程中并没有参考什么文章，文中的链接是半年多积累的书签和大家分享。文中忽略了许多技术细节，具体问题具体分析。还有一些概念没有涉及，比如：maven如何管理运行时参数。…
　　　　在写作过程中发现这几篇文章，对我帮助很大。

[*]Maven权威指南

[*]http://www.cnblogs.com/BigTall/archive/2011/03/23/1993253.html

[*]http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered （have fun ^_^）
　　GoodNight.
　　@author ：Galaxias.Sapphire.REN
　　@Date    ：2015年7月3日02:12:04

页: [1]

运维网's Archiver

由MAVEN入手浅谈项目构建与管理