第一章 传统项目构建方式

    我们来回想一下,在没有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,就是用来解决以上这些缺陷的。

扫描二维码关注公众号,回复: 304387 查看本文章

猜你喜欢

转载自ywu.iteye.com/blog/2345153