第一章 传统项目构建方式

    我们来回想一下，在没有maven之前，我们是怎么来构建项目的。

以我们熟悉的工具eclipse，要创建工程，我们会new一个project或dynamic web project，然后是拷贝或编写配置文件，配置文件我们可能会放在src根目录下，也可能会在src目录下建个config或其他目录，用于存放配置文件；对于web项目，有些人也可能会将配置文件存放于WEB-INF目录下；接下来要拷贝lib，对于普通项目，可能会在工程根目录下建一个lib目录用于存放jar包，然后将jar包添加到classpath，对于web项目，直接将jar包拷贝到WEB-INF/lib目录下；比如，我们需要添加spring的jar包，我们可能会到spring的官网去寻找相应的jar包，然后一个个下载下来，添加到项目中；如果spring项目还依赖其他jar包，比如commons-logging，再去相应的官网下载，或者下载一个完整的带有依赖的包，里面包含了spring及其依赖，然后将这些jar包一并添加到工程；当然，对于有经验的老司机来说，他可能本地目录上已经下载过spring的jar包了，只需从磁盘中再拷贝一份，添加到工程中。接下来，开始编写代码，建立相应的包，开始开发。开发过程中需要不断编译，这一般是借助工具，一般会开启自动编译功能。开发完后，或者部分模块开发完成，需要测试，编写单元测试，我们可能会在之前相应的包下直接新建test类，好点的会在src下建个test源码目录，专门存放测试相关代码。下图是传统方式创建的工程结构：

  测试完接下来是打包，一般会借助工具，如eclipse的export，导出完后将打成的jar包或war包上传到远程的服务器上，这个一般可以借助winscp等FTP工具上传，然后到服务器上启动服务。

  以上就是项目的构建过程，包括项目的创建、编译、测试、打包、部署等，我们每天都在做这些事。

  我们来总结下传统的构建方式的缺陷：

1、项目结构混乱 有些人喜欢把配置文件放在src根目录下，有些人放在WEB-INF目录下，有些人放在自己建的目录下，我们在拿到一个新项目的时候不得不去猜测配置文件存放的位置，我们希望的目标是，任何一个项目，都是自己熟悉的风格；

2、添加依赖麻烦 我们得去不同的官网下载jar包，有时候jar包不太好找，还得借助搜索引擎；另外，jar包下载后我们会存放到本地磁盘，jar包少的时候自己管理还比较好办，一旦jar包多了，不同的jar包，同一jar包的不同版本，我们可能就管理不过来了，磁盘上就很乱了，这个简直不能忍啊；另外，我们把jar包拷贝的项目中，每个项目都会独立在磁盘中存储一份jar包，虽然单个jar包体积不大，但项目多了，也是造成磁盘空间的浪费；

3、测试代码 以往我们的测试代码跟正式代码混在一起，规范点的，可能会在src下建立一个test目录，专门存放测试代码，但是在打包的时候，这些测试代码随同正式代码一并被打包了，发布到生产，而测试代码不应该发布到生产环境中；

4、编译、打包、部署太多的手工劳作 传统项目构建中，编译还好，我们会借助工具的自动编译功能，但是测试、打包、部署，这些都需要手工操作，费时费力

  接下来我们要介绍的maven，就是用来解决以上这些缺陷的。