maven具体使用遇到的问题记录及解决方法.docx
- 文档编号:9705776
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:43
- 大小:852.47KB
maven具体使用遇到的问题记录及解决方法.docx
《maven具体使用遇到的问题记录及解决方法.docx》由会员分享,可在线阅读,更多相关《maven具体使用遇到的问题记录及解决方法.docx(43页珍藏版)》请在冰豆网上搜索。
maven具体使用遇到的问题记录及解决方法
这是有关maven学习使用过程中,碰到不同问题时,从各种资料上获取的问题解答,包括一些网上的,还有一部分自己总结的,以作记录
1.pom.xml文件中exclusions用来排除传递性依赖
举例说明:
2.pom.xml中,scope的作用
scope代表依赖的范围,主要包括:
(1)compile
编译依赖范围,对于编译、测试、运行三者classpath都有效
举例如下:
--jersey-->
(2)test
测试依赖范围。
只对测试classpath都有效
--Junit-->
(3)provided
已提供依赖范围。
使用此依赖范围,对编译、测试classpath都有效,但在编译主代码时无效。
典型例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要maven重复引入
(4)runtime
运行时依赖范围。
对于测试、运行都有效,但在编译主代码时无效。
比如JDBC的驱动实现
(5)system
系统依赖范围。
同provided依赖范围。
但是用system依赖范围时必须通过systemPath元素显式的指定依赖文件的路径
3.可选依赖
有时,我们不想让依赖传递,那么可设置该依赖为可选依赖,将元素optional设置为true
举例:
4.通过eclipse管理依赖
打开项目,双击pom.xml,可以看到pom.xml的详细内容,点击“dependencyhierarchy”,可以看到当前项目的pom.xml已经存在的各种依赖关系
如果想增加一个依赖,可以点击“dependencies“,点击右边的”add“按钮,从maven中央仓库中搜索你想要的依赖
5.转换普通web项目至mavenweb项目
(1)准备一个简单的java项目
(2)转换为mavenproject,设置pom.xml
在eclipse中,右键单击“test913”,选择configure→converttoMaven
Project
根据提示,填写pom.xml中的各项信息
点击“finish”,生成项目的pom.xml文件
打开pom.xml可以看到,之前填写的所有信息
(3)修改pom.xml,添加依赖的jar包
举例来说,添加junit
Maven支持java开发中的多种依赖,可以前往maven远程中央仓库http:
//search.maven.org,搜索你想要的各种依赖包
另外一种方法,就是搭建自己的本地私服nexus
比如我自己创建的maven中央仓库:
http:
//192.168.201.14:
8081/nexus/index.html
这样,本地开发人员无需前往远程仓库下载更新各种依赖,而直接从本地私服获取,节约时间和带宽
比如上面提到的junit,我们可以在http:
//192.168.201.14:
8081/nexus/index.html查询到
登陆nexus,在搜索栏输入:
junit
(4)在pom.xml中添加资源库
如第(3)点最后的描述,构建过程,可能需要调用各种依赖jar包,这就pom.xml添加资源获取的仓库
为test913项目的pom.xml中,添加本地资源库目录,如上图,增加一个获取资源等各种jar包的目录地址
这里对pom.xml的操作只针对“test913“这一个项目,如果想设置成对本机所有项目都从nexus上获取资源,需要修改M2_HOME/conf/settings.xml,这里的settings.xml是全局范围的,使用整台机器上的所有用户都会受到该配置的影响。
还有一个办法,是先将M2_HOME/conf/settings.xml复制到~/.m2/settings.xml,然后对这里的settings.xml进行修改。
这样的原因,可以只针对当前用户产生作用。
我在这里,仍然是修改M2_HOME/conf/settings.xml
由于我们不能直接在settings.xml中插入
这里的local-nexus仓库指向了刚才我们配置的Nexus中“PublicRepositories”仓库组,也就是说,所有该仓库组包含的仓库都能供我们使用。
此外,我们通过
修改完settings.xml,Maven就会从你的Nexus服务器下载构件了,这样我们就可以全局的使用这个配置,不再需要为每个项目的POM做重复的配置了。
(5)设置自动发布构件至资源库(nexus)
有时候有个jar文件你无法从公共Maven仓库找到,但是你能从其它得到这个jar文件(甚至是POM),那么你完全可以将这个文件部署到Nexus中,使其成为标准流程的一部分。
比如:
团队在开发一个项目的各个模块,为了让自己开发的模块能够快速让其他人使用,你会想要将snapshot版本的构件部署到Maven仓库中,其他人只需要在POM添加一个对于你开发模块的依赖,就能随时拿到最新的snapshot。
为了能将项目的jar包上传到我们的资源库(nexus)并被其他maven项目依赖,需要在pom.xml中配置上传资源库
如上图,在pom.xml中配置distributionManagement,这里的url都是nexus安装成功后自动分配好的。
这里我们配置所有的snapshot版本构件部署到Nexus的Snapshots仓库中,所有的release构件部署到Nexus的Releases仓库中。
(6)设置setting.xml
由于部署需要登陆,因此我们在M2_HOME/conf/settings.xml中配置对应Repositoryid的用户名和密码。
为保证项目的jar包能正确上传,还需要确定本地maven的配置文件settings.xml中有对应上传资源库的用户名和密码。
其配置如下:
注意,在setting.xml中设置server时,填写的id要和pom.xml的配置distributionManagement时写的id名称要一致
账号和密码都是nexus自动生成的
(7)执行mvncleandeploy
全部配置完成,对test913项目执行mvncleandeploy
然后,你会看到maven将项目构件部署到Nexus中,浏览Nexus对应的仓库,就可以看到刚才部署的构件。
当其他人构建其项目时,Maven就会从Nexus寻找依赖并下载
出现:
buildsuccess
打开http:
//192.168.201.14:
8081/nexus/content/repositories/snapshot,查看是否多了一个com/nfs/tet913,如下图
同时,在nexus的public目录中,也出现了com/nfs/tet913
6.nexus本地资源库中的三种构件
Nexus预定义了3个本地仓库,分别为Releases,Snapshots,和3rdParty。
这三个仓库都有各自明确的目的。
Releases用于部署我们自己的release构件,Snapshots用于部署我们自己的snapshot构件,而3rdParty用于部署第三方构件,有些构件如Oracle的JDBC驱动,我们不能从公共仓库下载到,我们就需要将其部署到自己的仓库中。
Nexus预定义了“PublicRepositories”仓库组,默认合并所有预定义的Release仓库。
如下图:
7.nexus中搜索构件
可以通过搜索找寻我们需要的各种构件,在网站左边导航栏“ArtifactSearch”中,输入你想找的构件名称。
比如输入:
junit,敲回车,右边立刻会显示出junit的相关的构件信息。
你还精确搜索,通过限定group、artifact、version进行搜索
在网站左边导航栏“ArtifactSearch”下点击“advancedsearch”,点击下拉框,选择“Gavsearch”,输入group、artifact、version
8.项目组其他开发人员如何调用本地nexus中的jar
项目组开发人员编写出jar包,已经上传至nexus下的releases和snapshot中,会同步到http:
//192.168.201.14:
8081/nexus/content/groups/public下
其他开发人员如果想调用,首先得http:
//192.168.201.14:
8081/nexus/content/groups/public中查找,之前上传的jar
找到详细目录后,将XML描述整个复制进自己模块中的pom.xml文件中
将XML描述中的内容复制进自己开发模块下的pom.xml中,即可调用
9.struts框架的jar包
Struts是一个基于SunJ2EE平台的MVC框架,主要是采用Servlet和JSP技术来实现的。
作为java写的一个MVC框架组件之一,主要充当MVC中的Controllor(控制器)角色,Struts配合Spring与Hibernate可快速实现Java的Web应用开发。
为项目添加struts的依赖jar包:
(1)先进入nexus寻找struts
通过nexus仓库搜索struts,可以发现有113条和struts相关的构件
比如:
org.apache.struts
(2)将XML描述的依赖详情,复制进pom.xnl文件中
10.常用命令
mvn archetype:
create 创建Maven项目
mvn compile 编译源代码
mvn test-compile 编译测试源代码
mvn test 运行应用程序中的单元测试
mvn site 生成项目相关信息的网站
mvn clean 清除项目目录中的生成结果
mvn package 根据项目生成的jar
mvn install 在本地Respository中安装jar
mvneclipse:
eclipse生成eclipse项目文件
mvnjetty:
run 启动jetty服务
mvntomcat:
run启动tomcat服务
11.依赖关系
这个片断告诉我们,依赖的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,在构建项目上方便了很多。
12.依赖归类
13.聚合
所有用Maven管理的真实的项目都应该是分模块的,每个模块都对应着一个pom.xml。
它们之间通过继承和聚合(也称作多模块,multi-module)相互关联。
那么,为什么要这么做呢?
我们明明在开发一个项目,划分模块后,导入Eclipse变成了N个项目,这会带来复杂度,给开发带来不便。
为了解释原因,假设有这样一个项目,很常见的JavaWeb应用。
在这个应用中,我们分了几层:
Dao层负责数据库交互,封装了Hibernate交互的类。
Service层处理业务逻辑,放一些Service接口和实现相关的Bean。
Web层负责与客户端交互,主要有一些Structs的Action类。
对应的,在一个项目中,我们会看到一些包名:
org.myorg.app.dao
org.myorg.app.service
org.myorg.app.web
org.myorg.app.util
这样整个项目的框架就清晰了,但随着项目的进行,你可能会遇到如下问题:
这个应用可能需要有一个前台和一个后台管理端(web或者swing),你发现大部分dao,一些service,和大部分util是在两个应用中可。
这样的问题,你一周内遇到了好几次。
pom.xml中的依赖列表越来越长以重用的,但是,由于目前只有一个项目(WAR),你不得不新建一个项目依赖这个WAR,这变得非常的恶心,因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了,而且你根本不需要org.myorg.app.web。
有人修改了dao,提交到svn并且不小心导致build失败了,你在编写service的代码,发现编译不过,只能等那人把dao修复了,你才能继续进行,很多人都在修改,到后来你根本就不清楚哪个依赖是谁需要的,渐渐的,很多不必要的依赖被引入。
甚至出现了一个依赖有多个版本存在。
build整个项目的时间越来越长,尽管你只是一直在web层工作,但你不得不build整个项目。
某个模块,比如util,你只想让一些经验丰富的人来维护,可是,现在这种情况,每个开发者都能修改,这导致关键模块的代码质量不能达到你的要求。
我们会发现,其实这里实际上没有遵守一个设计模式原则:
“高内聚,低耦合”。
虽然我们通过包名划分了层次,并且你还会说,这些包的依赖都是单向的,没有包的环依赖。
这很好,但还不够,因为就构建层次来说,所有东西都被耦合在一起了。
因此我们需要使用Maven划分模块。
一个简单的Maven模块结构是这样的:
----app-parent
|--pom.xml(pom)
|
|--app-util
||--pom.xml(jar)
|
|--app-dao
||--pom.xml(jar)
|
|--app-service
||--pom.xml(jar)
|
|--app-web
|--pom.xml(war)
上述简单示意图中,有一个父项目(app-parent)聚合很多子项目(app-util,app-dao,app-service,app-web)。
每个项目,不管是父子,都含有一个pom.xml文件。
而且要注意的是,小括号中标出了每个项目的打包类型。
父项目是pom,也只能是pom。
子项目有jar,或者war。
根据它包含的内容具体考虑。
这些模块的依赖关系如下:
app-dao-->app-util
app-service-->app-dao
app-web-->app-service
注意依赖的传递性(大部分情况是传递的,除非你配置了特殊的依赖scope),app-dao依赖于app-util,app-service依赖于app-dao,于是app-service也依赖于app-util。
同理,app-web依赖于app-dao,app-util。
用项目层次的划分替代包层次的划分能给我们带来如下好处:
1.方便重用,如果你有一个新的swing项目需要用到app-dao和app-service,添加对它们的依赖即可,你不再需要去依赖一个WAR。
而有些模块,如app-util,完全可以渐渐进化成公司的一份基础工具类库,供所有项目使用。
这是模块化最重要的一个目的。
2.由于你现在划分了模块,每个模块的配置都在各自的pom.xml里,不用再到一个混乱的纷繁复杂的总的POM中寻找自己的配置。
3.如果你只是在app-dao上工作,你不再需要build整个项目,只要在app-dao目录运行mvn命令进行build即可,这样可以节省时间,尤其是当项目越来越复杂,build越来越耗时后。
4.某些模块,如app-util被所有人依赖,但你不想给所有人修改,现在你完全可以从这个项目结构出来,做成另外一个项目,svn只给特定的人访问,但仍提供jar给别人使用。
5.多模块的Maven项目结构支持一些Maven的更有趣的特性(如DepencencyManagement),这留作以后讨论。
接下来讨论一下POM配置细节,实际上非常简单,先看app-parent的pom.xml:
Xml代码
1. //maven.apache.org/POM/4.0.0" xmlns: xsi="http: //www.w3.org/2001/XMLSchema-instance" 2. xsi: schemaLocation="http: //maven.apache.org/POM/4.0.0 http: //maven.apache.org/maven-v4_0_0.xsd"> 3. 4. 5. 6. 7.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- maven 具体 使用 遇到 问题 记录 解决方法