Joinclass Inc  
软件开发 软件配置 项目管理 软件工程
公告
  • 本人联系方式: E-mail: tilanmaster@gmail.com msm: J.joy@msn.com
日历
统计
  • 随笔 - 53
  • 文章 - 52
  • 评论 - 67
  • 引用 - 0

导航

常用链接

留言簿(1)

随笔分类(53)

随笔档案(53)

文章分类(61)

相册

JAVA学习链接

搜索

  •  

积分与排名

  • 积分 - 84795
  • 排名 - 77

最新评论

阅读排行榜

评论排行榜

 
使用maven2一段时间了,我基本把我自己能够迁移的project都转换为maven2 project,以下是我的一点感想。

(原作者温少,转载请注明)

乱世盼英雄


现在的软件开发,比过去的软件开发要复杂得多。包括在参与开发的人数、代码规模、复杂的需求、依赖包的复杂性、使用到更多的技术、多个项目之间的复杂依赖关系。

现在的开发人员,要掌握的技术要比过去的开发人员要多,不是现在的开发人员比以前的开发人员本身更优秀,而是拥有更多的资料、更多的学习机会、更多更大规模的时间,同时软件行业也在发展。说一句题外话,老程序员,如果不与时俱进,靠老本,是无法和新一代程序员竞争的,当然,老程序员,拥有更多的经验,掌握新技术的速度更快,这又是另外一回事。

开发人员掌握的技术更复杂了,项目用得的技术自然也是更复杂,例如一个web项目,可能使用到很多技术,面向对象、泛型、or-mapping、依赖注入(spring-framework)、全文检索(lucene)、数据库、集群、工作流、web service等等。

由于使用了多种技术,这些技术可能是JDK提供的,也可能是第三方开源组织提供的,或者不同的商业公司提供的。

于是出现了一个新的难题,就是包依赖复杂性。以前,你很难想象你的代码依赖数十个不同开源组织、商业公司提供的库。例如,我们经常使用的log4j、junit、easymock、ibatis、springframework,每个组件都有悠久的历史,存在不同的版本,他们之间版本还有依赖关系。

项目依赖的复杂性,经常的,一个较大部门有10-30个项目是常事,项目之间有不同版本的依赖关系,部门与部门之间的项目也存在复杂的版本依赖关系。

Eclipse本身提供Project的依赖,但是简单的依赖显然解决不了问题。例如Project B依赖Project A,Project A依赖第三方的jar包abc-1.0.jar,那么需要在两个项目的lib下都存放abc-1.0.jar,这产生冗余,当Project数量多起来,这个冗余就产生了管理问题,如果需要将abc-1.0.jar升级为abc-1.1.jar,则需要在两个Project中同时修改,如果Project数量达到10个以上,而且是不同项目组维护的项目,这个就是非常麻烦的事情。而且Project A修改依赖,为啥需要Project B也作相应的修改呢?

需要解决此问题,就需要在Project A的包中描述其依赖库的信息,例如在META-INFO记录所以来的abc-1.0.jar等。Eclipse的plug-in拥有类似的方案,但是这样一来,就使得开发Project B的项目组,需要把Project A的代码从源代码库中check out出来。在依赖链末端的项目组是很惨的。

由于Project数量众多,关系复杂,dailybuild的ant脚本编写成了很麻烦的事情,使用Project依赖的方式,更加使得编写dailybuild ant script是非常痛苦的事情。

当然也可以不使用project依赖的方式,而使用artifact lib的依赖方式,但是artifact lib的依赖方式,就是同时修改多个project,互相调试时带来了痛苦。

在以前,我们面临这些问题时,唯一的感觉就是,这事情TMD的太麻烦,几乎是失控了。

maven的出现,解决这种问题看到了希望。maven出现的原因就是,现在的开发管理复杂度达到了一定程序,需要专门的开发管理工具,这样的工具需要涵盖开发的各个阶段,包括工程建立、配置依赖管理、编译、测试、产生分析报告、部署、产生制品等阶段。目前,各个阶段的工具都存在,但是不是集成的,对使用带来了很大麻烦。maven集成了这些工具,提高了统一的环境,使得使用更简单。

现在maven非常流行了,apache上所有java project都已经build by maven,其他跟进的开源项目非常多,例如mule、hibernat等等,商业公司也很多在采用,sun公司提供有maven2 repository。

现在,2007年,如果你还没采用maven project,你可能需要思考一下,是否你使用了不恰当的方式管理的代码,或者你落伍了?

maven的一些常用任务

compile 编译代码
test 运行单元测试
package 打包代码
site 产生报告,例如java doc、junit的通过率报告和覆盖率报告、findbugs的分析报告等等。
assembly 使用需求产生assembly,例如把生成一个程序目录,包括bin、config、lib、logs,把依赖包放在lib中。
deploy 部署制品到repository中。

这些都是常用的任务,在以前编写脚本很麻烦,现在在maven中,一切都是很简单,需要仔细设置时功能又强大到令人惊叹,例如site的fml,assembly。

maven资源库

maven官方提供了一个常用lib的资源库,包括apache的所有java项目,开源常用的基本都能够找到,例如mule、c3p0、easymock、hibernate、springframework、json等等,版本齐全,任你挑选。

可以部署本地资源库代理提高下载速度。使用maven proxy。

maven体系结构


maven使用plug-in的体系,使用很好的自动更新策略,本身用到的jar都是lazy download的,可以指定download的repository。这样,初始下载的maven是一个很小的程序,使用的时候从本地的资源库或者本地代理资源库高速下载lib。maven的插件体系,充分利用了internet的资源丰富和局域网的高速带宽,使用本地repository时,可以享受到每秒钟数M的下载速度,感觉就是,人生真是美妙!

elcipse的plug-in体系,就不是那么好用了,我们使用eclipse的find and install功能下载或者更新插件时,慢如蜗牛,依赖缺失时的烦恼,更新一个plug-in,可能耗费你数个小时,第三方的plug-in的下载服务器可能更慢,例如subversive的plugin-in,有一次我花了两天还没下载好,只好使用下载工具下载好,copy到plug-in目录下。此时,我们总是感叹,人生总是有很多烦恼事啊!

相比之下,高下立判!在此我不是说eclipse的plug-in体系结构设计不好,eclipse的插件体系非常优秀,但是还有很大改进空间!
posted on 2007-10-29 16:28 Joinclass Inc 阅读(1225) 评论(4)  编辑 收藏 引用 所属分类: 技术专题
评论:
  • # re: 应用maven的感想   I hate maven! Posted @ 2009-03-11 15:47
    极度难用,被框在它的哪些框架下,非常痛恨maven  回复  更多评论   

  • # re: 应用maven的感想   Ant + ivy Posted @ 2009-03-11 15:54
    最近开发一个带自己classloader的war。
    最后不得不用回ant+ivy,灵活的好,maven在应付一些复杂的过程性编译时,根本不像它说的那么简单,而且是根本无法解决。

    处理依赖conflict时,也不够灵活。

    不要浪费时间在maven上,有更多时间花在project才好。  回复  更多评论   

  • # re: 应用maven的感想    Posted @ 2009-04-28 22:12
    是的,非常难用。
    最好不要用maven。
    一般项目的Jar文件都是固定的。根本用不着那么多Jar包。
    用maven是自找苦吃  回复  更多评论   

  • # re: 应用maven的感想    Posted @ 2009-04-28 22:41
    maven的插件体系,充分利用了internet的资源丰富和局域网的高速带宽

    ---------------
    这种广告词太荒唐了。
    用maven实际上是:永远也下载不完。
    最近调查好几种open source的项目,每调查一个就要下载半天甚至一天的。maven太垃圾了。

    所以maven的广告词应该是:永远的下载和等待。  回复  更多评论   

只有注册用户登录后才能发表评论。
 
Copyright © Joinclass Inc Powered by: 博客园 模板提供:沪江博客