一.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.本来写完上述一些实际使用和简单介绍就想着差不多了,在网上看到一个比喻,觉得甚是生动,在这边也可以提一下。
我今天要做一道菜,需要一些原材料:
- 小排500克。
- 酱油20克
- 盐5克。
- 糖20克。
- 茴香5克。
- 姜,一个。
正常来说,我需要去菜市场买排骨,去粮油店买调料,再去香料店买香料等,如果这个菜单再复杂一些,我就需要去各种不同的地方买各种不同的原材料,费时费力。
这时候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这个工具,那么就可以省去负责上述事务性工作的人工了,同时也增加了程序猿的负担。
事实就是,越来越多这样的工具出现,程序员们被迫地去掌握这些工具,完成一些可能本来不属于自己的工作,但是在其他人看来,往往掌握这些工具的使用,是程序猿分内的事。
新的工具和框架会不停地出现以及迭代,程序员明明只是写代码的,但是却需要马不停蹄地去追逐新的开源工具,去掌握它们,来完成一些不是写代码的工作。