Maven知识梳理及使用

一.maven是干嘛的？有什么用？为什么要用它？

刚入职的时候，老员工给了一份文件，里面分别是java环境配置教程、java开发注意事项，再有一个就是eclipse创建maven项目教程。

maven的下载和安装，以及如何在ecplise里创建maven工程，这个网上已经有很多教程了，这里就不赘述。本篇文章着重讲一下maven到底可以给我们开发带来什么，根据我自己的实际使用感悟来记录。

最开始我对maven只有一个简单的概念，就是这个maven是做项目管理的，不知道出于什么心理，高技术的总是反感做项目管理(甚至是所有行政类)的，所以我在开发一段时间后，对maven项目、SSM框架等皆生出一股没由来的厌恶，我决定在不使用maven和框架的情况下，自己用原始的java工程来完成一些项目，很快我就遇到了一些困难，正是从这些困难上，明白了企业级工具和框架的作用。

1.依赖

java项目总是少不了依赖，个人理解，依赖有两个维度

①jar包依赖

面向对象的语言，我们只需要解决问题，调用各种方法，有太多太多的方法我们不需要自己去实现，只需要会用会调即可，这在应用开发几乎是最重要的一环。java本身会有一些包，里面有一些基础方法，但是总有一些方法，需要取调用一些第三方包，这个时候maven的作用就显现出来了。我们不需要像传统项目一样，手动的去找到这个jar包，下载下来，然后放入jdk里，或者项目的lib文件夹下，我们直接去maven的库里找，如果有的话直接添加依赖，没有的话就像一个大仓库，不需要你一个人去完善，是所有的人都可以往里放东西，放的东西大家都能用。

        <dependency>
			<groupId>com.aliyun.openservices</groupId>
			<artifactId>aliyun-openservices</artifactId>
			<version>1.0.12</version>
		</dependency>

②项目依赖

有时候，我们想要调用的方法或者类，是在我们写过的另外一个项目里，或者其他同事写的项目里，我们需要去调用另外一个项目，也就是说，我们现在写的项目要与另外一个项目互相依赖，这个是项目层级的，用手动添加jar包的方法是搞不定的，但是对于maven添加依赖的功能来说没有区别，POM文件里dependency一加，非常简单快捷。

        <dependency>
            <groupId>com.xxx.lrt</groupId>
            <artifactId>ms-business-auth</artifactId>
            <version>${project.version}</version>
        </dependency> 

2.项目属性

项目架构是一个问题，在大型的企业级项目里，往往是拥有庞大的复杂的架构，某个员工只是负责 其中某一个子项目的开发，甚至是子项目里的子模块，这个其实也就是模块化开发。有子就有父，子项目一般不独立存在，需要与父项目建立关联，需要从父项目继承很多代码下来，同时也要有自己的标记、自己的版本，maven的一部分功能就是做这个的。

<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>
  <parent>
    <groupId>com.xxx.lrt</groupId>
    <artifactId>ms-business</artifactId>
    <version>1.0.0</version>
  </parent>
  <artifactId>ms-business-maintaining-web</artifactId>
  <packaging>war</packaging>
  <name>maintaining-system</name>

很多东西并不是说非得这么做，也不是说只有maven能做到，只是maven用起来很方便，很适合用于大型项目、多人开发、多次迭代的场景。

3.打包与部署

用的最多的命令就是 mvn clean -DskipTests package -P prod

这里的prod指的是项目pom文件里的配置，这个其实不仅仅是maven的知识点了，跟SSM整体框架也有关系，总的来说就是把你目标环境的配置信息写在一个profile里，包含了数据库地址，账号密码，多个数据源，还有一些关于shiro的地址，然后给你的这一整份数据源配上一个id，正式版一般叫prod，测试版可以叫test。这样做的目的就是为了区分测试环境和正式环境，本地开发和测试阶段，运行时选择test，正式上线的时候选择prod来进行打包即可。

 执行完毕之后，war包会放到target目录下，拿出来放到服务器上即可。

4.项目目录划分

这个还是要提一下，以下是一个普通的java工程，长这样：

就只有两个目录，一个src放代码，一个library放包，配置文件放哪儿？单元测试代码放哪儿？没有统一的标准，如果一个团队的人在这种情况下开发，那就是八仙过海各显神通，会把这个项目的目录倒腾的乱七八糟。接下来看maven的工程目录：

 

可以看到，对源代码、单元测试、配置文件、资源包等都有专门的路径规划，该放哪儿的放哪儿，大家都有一个规范，也就不会去乱放文件 。

二.理解

1.本来写完上述一些实际使用和简单介绍就想着差不多了，在网上看到一个比喻，觉得甚是生动，在这边也可以提一下。

我今天要做一道菜，需要一些原材料：

1. 小排500克。
2. 酱油20克
3. 盐5克。
4. 糖20克。
5. 茴香5克。
6. 姜，一个。

正常来说，我需要去菜市场买排骨，去粮油店买调料，再去香料店买香料等，如果这个菜单再复杂一些，我就需要去各种不同的地方买各种不同的原材料，费时费力。 

这时候maven出现了，它就像一个专卖店，你要用那么多种材料做出一道叫做红烧排骨的菜，你来maven，它直接给你一个组合包，里面包含你所需要的所有的原材料，一个地方，全部买齐。

上述这个例子相当生动地描述了maven在管理jar包方面的作用，其实还有一个很烦人的地方，我上面的文章没提到，就是你手动去下载jar包的时候，经常会出现jar包与jar包互相依赖的情况，比如我需要1，我下载了1发现1用不了，因为1还依赖了2，我又要去下载2，结果发现2还需要依赖一个3，直接裂开，最后你往往只需要一个jar包里的一个方法，但是你却去了很多不同的网站下载了几十个jar包，而且这几十个jar包你都需要找对版本，其中一环出现问题，其他的就用不了了。

maven帮我们解决这个问题，它自己会去递归地下载目标jar包以及目标jar所依赖的其他jar包，还能兼顾版本，不会搞错，非常方便。

2.看到的另外一种比喻，稍显刻薄但是也不无道理：把软件开发过程中本该专人负责的事务性工作伪装成一门“技术”推给程序猿，以便降低人工成本的一个工具。

这么说可以说是新视角看maven，我觉得还是有些道理的。不管是目录构建、资源包下载，资源包仓库的构建这些应该都是专人来负责的，他们跟写代码搞开发可能没多大关系，属于一些事务性的工作，但是有了maven，你只需要告诉成员怎么去使用maven这个工具，那么就可以省去负责上述事务性工作的人工了，同时也增加了程序猿的负担。

事实就是，越来越多这样的工具出现，程序员们被迫地去掌握这些工具，完成一些可能本来不属于自己的工作，但是在其他人看来，往往掌握这些工具的使用，是程序猿分内的事。

新的工具和框架会不停地出现以及迭代，程序员明明只是写代码的，但是却需要马不停蹄地去追逐新的开源工具，去掌握它们，来完成一些不是写代码的工作。