maven具体使用遇到的问题记录及解决方法.docx
《maven具体使用遇到的问题记录及解决方法.docx》由会员分享，可在线阅读，更多相关《maven具体使用遇到的问题记录及解决方法.docx（43页珍藏版）》请在冰豆网上搜索。
maven具体使用遇到的问题记录及解决方法
这是有关maven学习使用过程中，碰到不同问题时，从各种资料上获取的问题解答，包括一些网上的，还有一部分自己总结的，以作记录
1.pom.xml文件中exclusions用来排除传递性依赖
举例说明：
com.sun.jersey.contribs
jersey-spring
${jersey.version}
org.springframework
spring
org.springframework
spring-core
org.springframework
spring-web
org.springframework
spring-aop
org.springframework
spring-beans
org.springframework
spring-context
2.pom.xml中，scope的作用
scope代表依赖的范围，主要包括：
（1）compile
编译依赖范围，对于编译、测试、运行三者classpath都有效
举例如下：
javax.ws.rs
jsr311-api
${jsr311.version}
jar
compile
--jersey-->
com.sun.jersey
jersey-servlet
${jersey.version}
jar
compile
（2）test
测试依赖范围。
只对测试classpath都有效
--Junit-->
junit
junit
${junit.version}
test
（3）provided
已提供依赖范围。
使用此依赖范围，对编译、测试classpath都有效，但在编译主代码时无效。
典型例子是servlet-api,编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要maven重复引入
javax.servlet.jsp
jsp-api
${jsp.version}
provided
javax.servlet
servlet-api
${servlet.version}
provided
（4）runtime
运行时依赖范围。
对于测试、运行都有效，但在编译主代码时无效。
比如JDBC的驱动实现
（5）system
系统依赖范围。
同provided依赖范围。
但是用system依赖范围时必须通过systemPath元素显式的指定依赖文件的路径
3.可选依赖
有时，我们不想让依赖传递，那么可设置该依赖为可选依赖，将元素optional设置为true
举例：
commons-logging
commons-logging
1.1.1
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中插入元素，这里我们编写了一个profile，并添加了一个profile并使用元素自动将这个profile激活。
这里的local-nexus仓库指向了刚才我们配置的Nexus中“PublicRepositories”仓库组，也就是说，所有该仓库组包含的仓库都能供我们使用。
此外，我们通过和元素激活了Maven对于仓库所有类型构件下载的支持，当然你也可以调节该配置，比如说禁止Maven从Nexus下载snapshot构件，只要将“true”改成“false”即可。
修改完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
org.apache.struts
struts2-core
2.3.15.1
（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.依赖关系
org.hibernate
hibernate
3.1
jar
runtime
这个片断告诉我们，依赖的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.0.0
4. org.myorg.myapp
5. app-parent
6. pom
7.
升级会员 