JAVA—咖啡馆

——欢迎访问rogerfan的博客,常来《JAVA——咖啡馆》坐坐,喝杯浓香的咖啡,彼此探讨一下JAVA技术,交流工作经验,分享JAVA带来的快乐!本网站部分转载文章,如果有版权问题请与我联系。

BlogJava 首页 新随笔 联系 聚合 管理
  447 Posts :: 145 Stories :: 368 Comments :: 0 Trackbacks
Maven做项目管理
在Java世界中我们很多的开发人员选择用Ant来构建项目,一个build.xml能够完成编译、测试、打包、部署等很多任务,但我们也碰到了很多的问题,如jar文件管理混乱,各个项目结构和build.xml相差很大等等。而Maven的出现,给项目提供了更多的支持。
1        简介
Maven作为Apache的一个开源项目,旨在给项目管理提供更多的支持,主页地址为http://maven.apache.org 。它最早的意图只是为了给apache组织的几个项目提供统一的开发、测试、打包和部署,能让开发者在多个项目中方便的切换。很多伟大的事业,出发点都很简单,ebay就是很好的例证。而maven的成功又一次验证了这一点,越来越多的项目开始使用maven
基本原理
Maven的基本原理很简单,采用远程仓库和本地仓库以及一个类似build.xml的pom.xml,将pom.xml中定义的jar文件从远程仓库下载到本地仓库,各个应用使用同一个本地仓库的jar,同一个版本的jar只需下载一次,而且避免每个应用都去拷贝jar。如图1。同时它采用了现在流行的插件体系架构,只保留最小的核心,其余功能都通过插件的形式提供,所以maven下载很小(1.1M),在执行maven任务时,才会自动下载需要的插件。
这个基本原理与Pear――PHP扩展与应用库(the PHP Extension and Application Repository)的原理非常相似,都有一个官方的仓库,都是微内核,通过网络将需要的文件下载到本地,通过官方仓库将相应的类库进行统一管理。Pear已经成为PHP开发事实上的标准,而Maven在Java世界的地位也逐渐加强,成为标准指日可待。
另外由于插件的易开发性,现在有了非常多的可供选择的插件,如与eclipse结合的插件,与test相关的插件,后面我们结合maven在项目中的使用进行详细介绍。
图1
2        项目管理
Maven官方把maven定义为一个项目管理工具,我们不妨看看maven能给我们的项目提供哪些好的支持。
2.1       项目标准化
Maven一个重要特性是定义了项目的标准模板,官方说法是最佳实践。可以通过命令:mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app创建一个单一的maven项目。创建好的项目,具有了特定的项目结构。这个项目结构是参考业界的最佳实践而成,为后面使用统一的maven命令打下了基础,如测试mvn test、打包mvn package等,无需写一行脚本,就可以方便的实现众多功能。Maven还提供其它一些类型模板,可以通过添加-DarchetypeArtifactId={type}创建,如-DarchetypeArtifactId=maven-archetype-site,生成site类型的项目。
同时一些好的开源软件使用了maven,也能作为很好的项目模板,如Equinox(Appfuse的简化版),它的pom定义了对hiberante,spring…的依赖,可以通过ant new -Dapp.name=NAME快速生成项目原型,然后对pom文件进行裁减,以符合自身项目的需要。
有了这个标准,项目间能方便的进行交流,你也很容易了解其它使用maven项目的结构。对于企业来说,引入maven就自然引入了规范,这可比费时费力的写文档,定规范有效的多了。
2.2       文档和报告
使用mvn site可以快速生成项目站点,apache很多开源项目站点都采用maven生成,会出现built by maven字样的图标。
maven提供的针对如junit,checkstyle,pmd等的插件,能够方便的进行测试和检查并能直接生成报告。使用都很简单,如mvn surefire-report:report 就能自动进行junit测试,并生成junit报告,mvn pmd:pmd生成pmd报告。具体使用可以在http://maven.apache.org/plugins/index.html找到。
2.3       类库管理
Maven一个很重要的特色就是类库管理。通过在pom.xml中定义jar包版本和依赖,能够方便的管理jar文件。以下是一个简单的jar定义片断:
<dependency>                                                                      
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.1</version>
      <type>jar</type>
      <scope>runtime</scope>
 </dependency>
这个片断告诉我们,依赖的jar包groupId为org.hibernate,artifactId为hibernate,版本为3.1,scope为runtime。在实际项目中,会将M2_REPO(maven本地仓库地址)/ org/hibernate / hibernate /3.1/ hibernate -3.1.jar放入classpath。
同时maven会通过pom.xml管理jar包间的依赖。比如上面的hibernate-3.1.jar同级目录肯定会有一个hibernate -3.1.pom,在这个pom文件中指定了这个jar对其它一些jar的依赖。而这个pom文件是远程仓库提供,无需进行修改,执行maven相关命令就会自动根据相关依赖去下载jar包。这样只需定义对hibernate的依赖而无需关心相关jar,在构建项目上方便了很多。
因为pom文件对jar的管理,也产生了一个很吸引人的特性:项目文件很小。以往一个web项目中,jar文件都要放入WEB-INF/lib下,并放入cvs(svn)中,很容易就达到几十M。而通过maven,只需一个pom.xml,在执行mvn eclipse:eclipse时再去远程仓库下载,项目文件一般只需几百K。
2.4       发布管理
使用maven可以方便的进行项目发表管理。在项目开发到一定阶段,可以使用mvn package打包,它会自动先运行mvn test,跑所有的testcase,只有全部通过才能正确打包。生成的war包(如果项目的packaging为war)在target目录下。这个war包与使用ant脚本生成一样,但无需一行脚本,这也是maven对比ant的优势之一。使用mvn install将编译和打包好的文件发布到distributionManager指定的远程repository。使用mvn deploy可以自动管理项目版本。
 
3        使用maven
Maven使用简单,插件丰富且经过大量项目考验,在项目中引入的风险很小。笔者在项目中使用maven,新进员工在半小时内就能成功使用maven构建项目,并很快掌握几个常用的命令。Maven也不需要什么特殊的设施。如果项目全部使用开源软件,并且不需要maven管理项目版本,只需要一个SCM环境(CVS或SVN),共享开发源码就可以。把pom.xml中的repository设为官方地址就行,配置如下:
<repository>
      <id>central</id>
      <url>http://www.ibiblio.org/maven2</url>
</repository>
这个官方remote repository上有非常多的开源软件,应该能满足大部分项目的需要。如果有项目需要而它上面暂时还没有的软件,或者希望使用公司内部的软件,那么就需要自己配置一个repository了。
3.1       自建私服
传奇私服大家应该都听过,一个网吧自己搞个私服,一伙人免费在上面砍杀。官方因此少赚了很多钱,因此总想打击。而maven官方却对自建私服很是支持,我们总算可以正正当当搞把私服了(Springside的老大江南白衣就是创建私服的好手)。我们就来介绍下自建私服的最快方法。
首先需要一个http server,找台服务器装上apache就行。放一个空的maven目录到htdocs下,假设服务器ip为192.168.0.1,确认能用http://192.168.0.1/maven访问到。然后在自己机器上装好maven2,初始化好项目,在pom.xml放入需要的jar定义,运行如mvn eclipse:eclipse就自动从官方下载jar到本地,如果不做配置,默认本地repository为${user.home}/.m2/。对于windows xp来说一般在C:\Documents and Settings\%username%\.m2下,其中%username%为操作系统登录用户名。这时你可以看到${user.home}/.m2/下多了个repository目录,里面有很多的项目相关jar,目录按groupId/ artifactId/version排好。把repository目录整个拷贝到apache服务器的maven目录下,如果需要官方缺少的jar或公司内部jar,仿照这个目录结构,做好jar放到maven目录下。自建私服成功!
要使用私服,只需修改pom.xml,在repository配置后加上:
<repository>
      <id>companyName</id>
      <url>http:// ${ip}/maven</url>
</repository>
这样需要下载jar时,会先到本地repository查看,没有下载过再到官方搜索,没有找到再到后面的repository查找。
3.2       安装配置
Maven的安装很简单:
1.         从apache网站上下载maven安装包,实际上就是个压缩文件。将其解压到你想要存放maven的目录中。在这里假设你将maven解压到C:\Program Files\Apache Software Foundation\maven-2.0.4中。
2.      C:\Program Files\Apache Software Foundation\maven-2.0.4\bin设到你的系统环境变量%PATH%中。
3.      同时确保你已经将你的JDK安装目录设为java_home系统变量。
4.         打开个命令行窗口,运行mvn –version验证是否安装成功。
5.         如果使用eclipse,在运行mvn eclipse:eclipse生成eclipse项目文件后,需加入M2_REPO到Classpath Variables中,指向本地repository,例如:C:/Documents and Settings/Owner/.m2/repository。
3.3       基本使用流程
在项目进程中,不必做什么配置,在pom.xml同级目录,cmd使用简单的maven命令,就可以完成初始化->开发->测试->发布的全过程。Maven的基本使用流程如下图:

 

 

其中在初次使用命令mvn eclipse:eclipse时会下载很多的插件和jar,可能需要较长的时间,建议泡杯咖啡,和同事吹吹牛。如果失败,可能是网络问题,可以重新运行mvn eclipse:eclipse,已下载好的插件和jar不会再下。运行mvn test和mvn package等命令,产出物都会放在target目录下。如果在使用过程中有什么问题,也可以和我联系,mail:pesome@gmail.com,我们一起来尝试解决。
 
总结:
Maven作为新的项目管理工具,简单易用,能对项目的各个阶段提供大力支持,同时由于它易扩展的插件体系架构,出现了越来越多的插件,也使得其功能更加强大。短短一篇文章,实在很难把其特点一一尽述,maven还有很多好用的功能和插件等待我们去使用和开发。而学习新技术的最好方式就是实践,大家如果有兴趣,尽快下载一个最新版,开始你的maven之旅吧!
 
 
参考文档:
1.       http://maven.apache.org 官方网站文档
2.       http://www-128.ibm.com/developerworks/cn/opensource/os-maven2/ Maven2的新特性

Maven 出现到现在也有很长时间了,初识它的感觉至今仍清晰的印在脑海中。现在想来,当时从 Ant 移情 Maven 的想法其实很朴素,就是因为 Maven 可以以网站的形式展现与项目相关的信息,如开发人员列表、各种 Report。这种方式为项目的构建带来了极大的方便,尤其是 Report 的。试想对于产生的 Junit-Report、JavaDoc、CheckStyle、PMD 等报告,如果没有一个统一的入口,每次切换目录是多么令人厌烦的事情!

Maven 无疑是相当成功的,这一点从越来越多的开源项目开始使用 Maven 就可以看出。Maven 取得成功的原因很简单:在简化构建脚本的同时,功能并没有缩水,反而有所增强;提供汇集项目信息的工具,并以相当友好的方式呈现;丰富的插件简化了工作。如此有力的工具出现,自然是争相使用。

新特性

如今 Maven2 已经推出,Maven 的官方网站称,Maven2 相对于 Maven1 是一个相当大的转变,甚至不惜牺牲兼容性来达到这一目的。(为了 Maven1 的用户着想,Maven1 仍在继续他的使命。)如此大的变动到底换来了什么样的结果?

1. 更快、更简单

比起 Maven1 那不急不慢的运行速度,Maven2在速度上有了质的飞跃,甚至与Ant相比也毫不逊色(当然,下载不算)。除此之外,"简化工作,使用业界公认的最佳实践"也是是 Maven2 的另一大主题,其他的新特性无处不在体现 Maven2 为简化工作而做出的努力。

2. 更少的配置文件

Maven1 和 Maven2 主要配置文件的对比:

  • Maven1:project.xml、maven.xml、project.properties和build.properties。
  • Maven2:pom.xml和settings.xml。

POM是Maven的核心对象模型,在Maven2中POM已由project.xml转移到pom.xml中使用,版本也由3升级为4。对于项目,一般只需要pom.xml就行了。

在Maven2中不需要也不提倡使用maven.xml,原因如下:

  • plugin的易用性的增强。
  • 散布于maven.xml中的内容难以在不同项目间共享,也不利于维护。在Maven2中建议使用自定义的plugin来封装这些内容。

如果仍期望能够使用类似maven.xml的功能,如<preGoal>,请参考Inserting non-standard build steps using preGoals and postGoals。

在Maven2中,配置使用settings.xml,它取代了原有的project.properties和build.properties。配置在Maven2中存在两种级别:

  • 用户级,针对操作系统登录用户而言。一般在$home/.m2/,对于windows用户,就是目录:C:\Documents and Settings\用户名\.m2\settings.xml。
  • 全局级:一般在%M2_HOME%/conf/settings.xml,M2_HOME是Maven2的根目录环境变量名。

在settings.xml中可以配置,如本地Repository、proxy等等,关于settings.xml的结构可以从Maven的官方网站上获取。

3. Plugin语言更换

在Maven2中,编写plugin的语言由jelly变更为Java和BeanShell。Java在速度上更有优势,而且开发人员的熟悉程度更高。对于其他的流行脚本,如groovy,Maven的官方网站的意见是,等待其更成熟时再考虑

4. 提供预定义的目录模板

好的目录结构可以使开发人员更容易理解项目,为以后的维护工作也打下良好的基础。Maven2根据业界公认的最佳目录结构,为开发者提供了缺省的标准目录模板。Maven2的标准目录结构如下:



使用目录模板,可以使pom.xml更简洁。因为Maven2已经根据缺省目录,预定义了相关的动作,而无需人工的干预。以resources目录为例:

  • src/main/resources,负责管理项目主体的资源。在使用Maven2执行compile之后,这个目录中的所有文件及子目录,会复制到target/classes目录中,为以后的打包提供了方便。
  • src/test/resources,负责管理项目测试的资源。在使用Maven2执行test-compile之后,这个目录中的所有文件及子目录,会复制到target/test-classes目录中,为后续的测试做好了准备。

这些动作在 Maven1 中,是需要在 maven.xml 中使用<preGoal>或<postGoal>来完成的。如今,完全不需要在pom.xml中指定就能够自动完成。在src和test都使用resources,方便构建和测试,这种方式本就已是前人的经验。通过使用Maven2,使这个经验在开发团队中得到普及。

创建标准目录模板,可以通过如下命令:


mvn archetype:create -DgroupId=com.codeline.commons -DartifactId=codelineCommons

groupId和artifactId的含义与Maven1中的含义一样,参数artifactId的值会作为项目根目录的名字。除了建立相应的目录之外,Maven2还会创建缺省的pom.xml。

Maven2也考虑到:不同类型的项目需要拥有不同的目录结构。如创建web项目,可以使用命令:


mvn archetype:create -DgroupId=com.mycompany.app-DartifactId=my-webapp-DarchetypeArtifactId=maven-archetype-webapp

5. 生命周期的引入

在Maven2中有了明确的生命周期概念,而且都提供与之对应的命令,使得项目构建更加清晰明了。主要的生命周期阶段:

  • validate,验证工程是否正确,所有需要的资源是否可用。
  • compile,编译项目的源代码。
  • test-compile,编译项目测试代码。
  • test,使用已编译的测试代码,测试已编译的源代码。
  • package,已发布的格式,如jar,将已编译的源代码打包。
  • integration-test,在集成测试可以运行的环境中处理和发布包。
  • verify,运行任何检查,验证包是否有效且达到质量标准。
  • install,把包安装在本地的repository中,可以被其他工程作为依赖来使用
  • deploy,在整合或者发布环境下执行,将最终版本的包拷贝到远程的repository,使得其他的开发者或者工程可以共享。
  • generate-sources,产生应用需要的任何额外的源代码,如xdoclet。

如果要执行项目编译,那么直接输入:mvn compile即可,对于其他的阶段可以类推。阶段之间是存在依赖关系(dependency)的,如test依赖test-compile。在执行mvn test时,会先运行mvn test-compile,然后才是mvn test。

6. 新增Dependency Scope

在POM 4中,<dependency>中还引入了<scope>,它主要管理依赖的部署。目前<scope>可以使用5个值:

  • compile,缺省值,适用于所有阶段,会随着项目一起发布。
  • provided,类似compile,期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
  • runtime,只在运行时使用,如JDBC驱动,适用运行和测试阶段。
  • test,只在测试时使用,用于编译和运行测试代码。不会随项目发布。
  • system,类似provided,需要显式提供包含依赖的jar,Maven不会在Repository中查找它。

<scope>的使用举例:


<dependency><groupId>hibernate</groupId><artifactId>hibernate</artifactId><version>3.0.3</version><scope>test</scope></dependency>

7. 传递依赖,简化依赖管理

在Maven1中,需要把依赖所需要的包也一并列出。这对于使用类似如Hibernate的用户来说所操的心太多了,而且也不方便。在Maven2中实现了传递依赖,如此对于Hibernate所依赖的包,Maven2会自动下载,开发人员只需关心Hibernate即可。

注意:只有得到Maven支持的依赖,通常是plugin形式出现,才能获得这个特性。而且对于一些老的plugin,可能由于时间的关系不支持传递依赖。如至少在Maven 2.0.1中,对于Hibernate 2.1.2,仍然需要显式列出Hibernate 2.1.2所依赖的包。





使用简介

安装Maven2的步骤非常简单:首先从Maven官方网站下载相应的软件包,目前是Maven 2.0.1;然后解压,并设置环境变量M2_HOME= Maven2的解压安装目录;最后将%M2_HOME%/bin添加到path中,方便Maven在任何目录下运行。

Maven2的运行命令是mvn,使用mvn -h可以获得相关的帮助信息。常用情形:

  • 创建Maven项目:mvn archetype:create
  • 编译源代码:mvn compile
  • 编译测试代码:mvn test-compile
  • 运行测试:mvn test
  • 产生site:mvn site
  • 打包:mvn package
  • 在本地Repository中安装jar:mvn install
  • 清除产生的项目:mvn clean

或许是由于刚刚推出的缘故,Maven2目前还是有一些不尽如人意的地方。尤其是Report部分的plugin,有的是因为目前还没有,如junit-report。有的则是一些莫名其妙的问题,如checktyle和pmd,在本地locale下都无法正常工作。以pmd举例,在产生PMD报告时会抛出如下异常:


java.util.MissingResourceException: Can't find bundle for base name pmd-report,locale zh_CN        at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:839)        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:808)        at java.util.ResourceBundle.getBundle(ResourceBundle.java:702)……

幸运的是,Maven2一出现就备受关注,要不了多长时间,诸如此类的问题应该就会很快解决。

结论

Maven2在Maven1的优势基础之上,又向前迈进了一大步。它提供的这些新特性大大地缩短了开发管理中的工作量,使得开发人员将精力集中在实际的业务问题上。而且这些新特性对于简化使用,普及最佳实践,也起到了积极的作用。

posted on 2009-07-13 14:35 rogerfan 阅读(162) 评论(0)  编辑  收藏 所属分类: 【开源技术】

只有注册用户登录后才能发表评论。


网站导航: