问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
一个多模块项目， 他们有一个共同的父模块:xx
当这个xx不存在的时候， 各个子模块可以单独编译吗
比如这几个子模块是A,B,C,D ， 虽然我把他们都拉到本地， 在B里执行maven的编译指令，仍然会报找不到A的错误。是因为我没有把他们的父模块拉到本地的原因吗？
接上2，那为什么，在eclipse里连接svn，我只把部分模块 check out as maven project , 就能编译成功呢？
公司项目模块太多。错综复杂。分为七八个库。一开始我是按照需要拉必要的模块下来。发现，总是报错。有的是莫名其妙的错误,明明模块是有传递依赖的，还是需要我手动添加等等。当我把各个库里的父pom拉下来。接着，项目完美运行了。这是什么原因呢？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
简单粗暴的办法，在公司内网用nexus建立私有的maven仓库，将稳定的模块发布上去。然后在项目的父pom添加仓库依赖。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
一般情况下如果是有父pom的，都是一些可重用的，底下很多子pom都要继承父pom实现依赖一些父类依赖好的。1.如果你需要用的依赖不是不是很多，可以查看你的子pom，看他依赖的是哪个父pom，拉下来到你本地就好。2.如果项目依赖太多，实在不方便一个个找的时候，你还是把你常用的一些依赖拉到本地吧，费点时间整理一下，以后用起来不折腾。
同步到新浪微博
分享到微博？
Hi，欢迎来到 SegmentFault 技术社区！⊙▽⊙ 在这里，你可以提出编程相关的疑惑，关注感兴趣的问题，对认可的回答投赞同票；大家会帮你解决编程的问题，和你探讨技术更新，为你的回答投上赞同票。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：漫谈依赖管理工具：从Maven,Gradle到Go
作者:51cto
为什么要有依赖管理工具?
谈依赖管理之前，我们先谈谈为什么要有依赖管理工具这东西。
我们学了一种编程语言，然后写了个&Hello World&，然后宣称自己学了一门语言，这时候确实不需要关心依赖问题。
然而，当你要写一个稍微复杂点的应用，那怕就是留言板这样的，需要读写数据库，就需要依赖数据库驱动，就会遇到依赖管理的问题了。
再进一步，你写了一个库，想共享给别人使用，更需要了解依赖管理的问题。
当然，如果项目足够简单，你可以直接将依赖方的源码放置在自己的项目中，或者将依赖库的二进制文件(比如jar，dll)放置在项目的lib里。要提供给别人呢?把二进制包提供下载或者给别人传过去。依赖管理工具出现之前大多数都是这样搞的。
但如果再复杂些，依赖库本身也有依赖怎么弄呢?将依赖压缩打包，然后放个readme帮助文件说明下，貌似也可以工作。
那如果你的项目依赖了好几个，乃至几十个库，而各库又有依赖，依赖也有自己的依赖，怎么办?怎么检测库的依赖是否有版本冲突?以后升级的时候怎么办?怎么判断lib目录下的某个文件是否被依赖了?
到这一步必须要承认需要有个依赖管理工具了，无论你使用任何语言。我们大约也清楚了依赖管理要做些什么。假设还没有依赖管理工具，我们自己要设计一个，如何入手?
1.要有一种依赖库的命名规则，或者叫坐标(Coordinates)的定义规则，可以通过坐标准确找到依赖的库。
2.要有对应的配置文件规则，来描述和定义依赖。
3.要有中心仓库保存这些依赖库，以及依赖库的元数据(metadata)，供使用方拉取。
4.还需要一个本地工具去解析这个配置文件，实现依赖的拉取。
以上其实就是各依赖管理工具的核心要素。
Maven诞生于2004年(来源维基)，查询了下，应该是各语言的依赖管理工具中早的。Ruby的gem也是2004年出现的，但gem离完备的依赖管理工具还差些，直到Ruby的bundler出现。Python的pip出现的更晚。
Maven的习惯是通过 groupID(一般是组织的域名倒写，遵循Java package的命名习惯)+ artifactId(库本身的名称) +
version(版本)来定义坐标，通过xml来做配置文件，提供了中心仓库(repo.maven.org)以及本地工具(mvn)。
依赖定义：&&&dependency&&&&groupId&com.google.guava&/groupId&&&&artifactId&guava&/artifactId&&&&version&18.0&/version&&&&/dependency&&&repo定义：&&&repository&&&&id&repo.default&/id&&&&name&Internal&Release&Repository&/name&&&&url&/nexus/content/repositories/releases&/url&&&&releases&&&&enabled&true&/enabled&&&&updatePolicy&interval:60&/updatePolicy&&&&checksumPolicy&warn&/checksumPolicy&&&&/releases&&&&snapshots&&&&enabled&false&/enabled&&&&updatePolicy&always&/updatePolicy&&&&checksumPolicy&warn&/checksumPolicy&&&&/snapshots&&&&/repository&&
同时，为了避免依赖冲突的问题，Maven的依赖配置提供了exclude配置机制，用于阻断部分库的传递依赖。
Ruby的gem，Node的npm，Python的pip，iOS的CocoaPods都类似，只是配置文件语法和坐标命名规则有些差异。
至此，看起来Maven很简单啊！为啥许多人会觉得Maven复杂呢?
主要在于以下两点：
1.Java这样需要编译的语言，发布的库是二进制版本的jar包，发布前需要有编译的流程，而依赖和编译是紧密相关的。不像Ruby，Node这样的脚本语言，将源码和配置文件扔到仓库就可以。
2.Maven并没有将自己单纯的定义为依赖管理工具，而是项目管理工具，它将项目的整个生命周期都囊括进去了。
第二点也是Ant+ivy和Maven思路上的区别，ivy认为已经有Ant这样的编译打包工具了，只需在上面做个插件解决依赖问题即可，而Maven认为Ant本身也有改进的地方，所以一并改造了。
Maven的改进的核心思路是：Convention Over Configuration
即&约定大于配置&。既然大多数人习惯都把源码目录命名为src，那就约定好都用这个目录，不用专门去配置。同样，clean，compile，package等也约定好，不需要专门定义Ant
task。这样既简化了配置文件，同时也降低了学习成本。一个Ant定义的项目，你需要阅读帮助文件或者查看build.xml文件才能了解如何编译打包，而Maven定义的项目直接运行&mvn
package&即可。
Java语言发明的比较早，初期这种思想还不普及，所以Java本身没有对项目的规范，而新的语言基本都吸收了这个思想，对项目都做了约定和规范。比如Go语言，如果用C/C++可能需要定义复杂的Makefile来定义编译的规则，以及如何运行测试用例，而在Go中，这些都是约定好的。
Maven定义为项目管理工具，包含了项目从源码到发布的整个生命周期：
validate&&&generate-sources&&&process-sources&&&&generate-resources&&&process-resources&&&compile&&&&process-classes&&&generate-test-sources&&&&process-test-sources&&&generate-test-resources&&&&process-test-resources&&&test-compile&&&&test&&&prepare-package&&&package&&&&pre-integration-test&&&integration-test&&&&post-integration-test&&&verify&&&install&&&deploy&
既然包含了这么多功能和阶段，所以Maven引入了插件机制，Maven本身的编辑打包等功能都是用插件来实现的，也允许用户自己定义插件。
同时涉及构建生命周期的不同的阶段，依赖也需要确定是编译依赖?测试依赖?运行时依赖?于是依赖多了scope的定义。
如果仅仅是这样把Maven理解成标准化的Ant+ivy+可扩展的插件框架即可?但现实世界的项目往往更复杂。
我们有了function用于组合代码块逻辑，有了object用于组合一组方法，有了package，namespace用于组合一组相关对象，但其实还需要有更高一个层次的组合定义
module，或者叫子项目。同一个项目下，不同的源码目录可能需要编译打包成不同的二进制文件，这些module共同构成了一个整体的项目。这个其实和源码管理习惯有关系，是每个独立的module作为单独的源码仓库呢？还是将相关的module全部放在一起?从降低沟通成本的角度考虑，还是应该通过一个大的仓库组织。
于是Maven引入了module的概念，同一个项目下可以有多个module，每个module有单独的pom文件来定义，但为了避免重复，Maven的pom文件支持parent机制，子项目的pom文件继承parent
pom的基本配置。可以说，module的机制将Maven的复杂度又提升了一个层次，很多人遇到Maven的坑多栽到这里了。
这里介绍一个Maven多项目版本管理的最佳实践：
1.父项目中配置版本号，子项目中不要显示配置版本号，直接继承父项目的版本号。
2.子项目之间的依赖通过${project.version}引用，不要明确配置版本号。
3.发布新版的时候，同时发布所有子项目，即便是该子项目未做变更。
4.最好通过Maven的release插件发布，避免手动修改版本号导致的不一致问题。
即便是这样，Maven的多项目版本管理经常也会遇到问题。主要是因为Maven的子项目之间的依赖也沿用的是第三方库依赖的配置方式，需要指定子项目的版本号。另外子项目的parent需要显式配置，也需要明确指定parent的版本号。一旦这些版本号出现错误，最后就会导致各种诡异的问题。
Maven的release插件使用也比较复杂，该插件其实做几个事情：
1.先构建一遍项目，确认项目可以正常构建。
2.修改pom文件的版本号到正式版，然后提交到源码仓库并打tag。
3.将该tag的源码检出，再构建一次，这次构建的jar包的版本是正式版的，将jar包上传到Maven仓库。
4.递增版本号，修改pom文件的版本号到SNAPSHOT，再次提交到源码仓库。
这个过程中，由于要构建两次，提交两次源码仓库，上传一次jar包，任何一步出错都会导致release失败，所以使用比较复杂。
到此，Maven的核心概念都分析完了，其他的都是插件机制上的一些扩展。大家也应该明白了Maven之所以最后变这么复杂的原因。
但无论如何，Maven基本上是项目管理工具的标杆了，有的语言直接通过扩展插件来用Maven管理，比如C++，C#(NMaven)，或者做了移植Byldan(C#)，不过貌似都是不太成功，估计主要原因应该是Maven是用Java写的，有社区隔膜。
Gradle对Maven的改进
聊了Maven的思路和优势，那Maven的缺点呢?这个我们和Gradle一起聊聊。Gradle就是在Maven的基础上进行的改进。优势主要体现在以下方面：
1.配置语言
Maven使用的是XML，受限于XML的表达能力以及XML本身的冗余，会使pom.xml文件显得冗长而笨重。而Gradle是基于Groovy定义的一种DSL语言，简洁并且表达能力强大。在Maven中，任何扩展都需要通过Maven插件实现，但Gradle的配置文件本身就是一种语言，可以直接依赖任意Java库，可以直接在build.gradle文件中像Ant一样定义task，比Ant的表达能力更强(Ant本身也是XML定义的)。
Gradle的配置文件中可以直接获取到Project对象以及环境变量，可以通过程序对build过程进行更细致的自定义控制，这个功能对于复杂的项目来说非常有用。
2.项目自包含(Self Provisioning Build Environment)
用户下载了一个Maven定义的项目，如果没用过Maven，还需要下载Maven工具包，了解Maven。但Gradle可以给项目生成一个
gradlew脚本，用户直接运行gradlew脚本即可，该脚本会自动检测本地是否已经有Gradle，没有则从网络下载，对用户透明(当然，国内网络下最好还是自己先下载好)。
对仓库的配置，Maven提供了一个本地的settings.xml配置文件，用于定义私有仓库以及仓库密码这样敏感的不应该放源码仓库里的文件。但这样带来的不便就是这些信息项目中没有自包含，所以Gradle干掉了这种本地配置的机制，所有的定义都在项目里。私有仓库密码这样的可以放在项目下的
gradle.properties文件里不提交上去，通过其他方式分享给内部成员。这点可能各有优劣。
3.任务依赖以及执行机制
Maven的构建生命周期的每一步都是预定义好的(参看前文)，插件任务只能在预留的生命周期中的某个阶段切入，虽然Maven的生命周期阶段考虑很充分，但有时候也不能满足需求。Maven会严格按照生命周期的阶段从开始线性执行任务，而Gradle则使用了Directed
Acyclic Graph来检测任务的依赖关系，决定哪些任务可以并行执行，这样使任务的定义以及执行都更灵活。
4.依赖管理更为灵活
Maven对依赖管理比较严格，依赖必须是源码仓库的坐标。虽然也支持system scope的本地路径配置，但还是有许多不方便之处(system
scope的依赖，打包的时候不包含进来)。如果世界上所有的库都通过Maven发布，当然没有问题，但现实往往不是这样的。这里要吐槽一下国内的各大厂发布的sdk之类的库，几乎都不提供仓库地址，就给个压缩包放一堆jar包进来，让用户自己搞定依赖管理问题。而Gradle在这方面比较灵活，比如支持：
compile&fileTree(dir:&'libs',&include:&'*.jar')&
这样的配置规则。
另外由于Gradle本身是一种语言，可以用编程的方式来管理依赖。比如大多数子项目都依赖某个库，除了个别几个，就可以这样写：
configure(subprojects.findAll&{it.name&!=&'xxx1&&&&&it.name&!=&&xxx2&})&{&&dependencies&{&&compile(&com.google.guava:guava:18.0&)&&}&&}&
5.子项目以及动态依赖机制
动态依赖主要是用来解决几个互相依赖的库都在快速开发期间的依赖问题，不能每次地层库修改发布新版本，上层库都要修改依赖配置文件，所以需要动态设置依赖最新版本。
Maven的解决方案是SNAPSHOT机制，子项目之间也是通过这个机制来实现依赖的。遇到的问题我们前面也分析了。
Gradle的虽然也兼容Maven仓库的SNAPSHOT机制，但它自己的版本管理机制上，并没有引入SNAPSHOT机制。它的依赖支持4.x，2.+这样的配置规则，实现动态依赖(注：Maven也支持类似的规则，参看
Dependency Version Requirement
Specification)。而子项目之间的依赖采用特殊的依赖配置，和第三方库的配置规则有区别。它直接使用：
compile&project(&:subpoject-name&);&
这样的配置，无需配置版本号，明确指定是子项目，避免Maven的子项目依赖带来的版本号问题。子项目的配置中也不需要显示配置父项目，只需要父项目单向中配置子项目列表即可。
同时Gradle的release机制也更为灵活，支持release到各种仓库(包括Maven仓库)，但不控制release过程中的版本号生成，修改源码仓库等步骤，留给用户自己通过手动或者CI工具，或者脚本去解决。
关于Gradle相对Maven的改进这里主要列举这几点，其他的可以参看Gradle官方的比较表格：maven_vs_gradle，这里不再详述。
Go语言的多项目以及依赖管理问题
最后再谈谈Go语言的多项目以及依赖管理问题。Go官方对这两方面并未做约定或者提供工具，于是只能各自想办法解决。多项目问题一般就是回归到了
Makefile+脚本的解决方案，比如kubernetes。依赖管理，开源社区多用Godeps，kubernetes用的也是这个。Godeps通过源码仓库路径以及源码tag来确定库的坐标，只管理依赖，有点像ivy，不关心构建过程。Godepes会将依赖库的依赖也添加到当前项目的依赖配置中，不是动态的依赖传递机制。没有scope，不区分是否是单元测试的依赖。一个仓库只支持一个配置，没有子项目概念，项目大了管理就比较复杂。另外它对传递依赖以及版本冲突的问题当前还是没有解决太好(有一些相关Issue)。
一个语言的多项目以及依赖管理方案对这个语言的生态发展有很大的影响，Java发展到现在，Maven以及Gradle功不可没，所以感觉Go官方应该对这两方面有所作为。Go语言迟迟没出依赖管理工具，个人觉得有几方面考虑：
1.Go尚未确定动态库的机制。编译型语言依赖最好也是二进制的，而不是源码。一方面可以加快编译速度，另外一方面也可以实现源码保护，方便分发以及代理缓存，让语言的适用范围更广。许多商业上的库是不方便提供源码的。所以依赖管理工具的实现需要动态库的机制。而动态库尚未确定的原因我觉得是Go
语言不想过早的引入二进制动态库的格式兼容问题，初期全部用源码是最省事的。
2.先让社区试试水，看看效果和反馈。
任何一个语言，发展到一定阶段都避不开依赖管理问题。前一段时间看到一篇写Go语言的文章，嘲讽Java的Maven构建个项目恨不能把半个互联网下载下来，我当时脑海中就浮现出长者的那句经典语录&图样图森破&。Go当前没遇到这些问题的原因只是Go还比较年轻，库还不够丰富，以及Go的很多项目还不够复杂。而像kubernetes这样的项目，当前依赖已经有226个了，构建一下，也快要下载半个Github了。所以个人觉得Go社区当前还是非常需要一个类似于Gradle的工具，来解决依赖管理，构建，多项目管理等问题。
官方微博/微信
每日头条、业界资讯、热点资讯、八卦爆料，全天跟踪微博播报。各种爆料、内幕、花边、资讯一网打尽。百万互联网粉丝互动参与，TechWeb官方微博期待您的关注。
↑扫描二维码
想在手机上看科技资讯和科技八卦吗？想第一时间看独家爆料和深度报道吗？请关注TechWeb官方微信公众帐号：1.用手机扫左侧二维码；2.在添加朋友里，搜索关注TechWeb。
小米MIX2到底长什么样，应该会比iPhone 8、Note 8更惊艳，你觉得这是吹牛吗？...
今天华为官方宣布亮黑版华为P10 Plus正式开卖，售价4888元。作为P10 Plus的第七款配色...
北京时间23日晚23点，三星将在纽约举办Galaxy新品发布会。
软银前总裁尼克什·阿罗拉（Nikesh Arora）认为，Uber下一任CEO的首要任务就是解决这...
腾讯公布2017年第二季度及中期业绩报告，微信和WeChat合并月活跃用户数达9.63亿，同比...
根据外媒 Apple Insider 的报道，主要为“物联网”设备提供芯片的美国制造商赛普拉斯...
两大游戏主机平台索尼PS和微软XBox都是自己单独开发的系统，其中索尼PS4系列主机最近...
今年4月，在UP 2017腾讯互动娱乐年度发布会上，腾讯宣布TGP平台正式升级为WeGame游戏...
妖刀姬手办虽然目前仍在监修中，不过已经复刻出了十足的英姿和美貌。......
善恶怎么判，正邪亦两难。《梦幻诛仙手游》新版本近日上线。......
八月，新的开始，新的故事，倩女手游全新篇章华丽开启！...
夜雾迷城活动2月22日5:00—2月28日23:59，本次活动新增套装黎明之冠新月之吻，下面为......
Copyright (C)
All rights reserved.
请选择一张图片分享
要转发到新浪微博，请
要转发到QQ空间，请&&&&&&&&&&&&&&&&&&
posts - 178,comments - 71,trackbacks - 0
& & & 做软件开发这几年遇到了许多的问题，也总结了一些问题的解决之道，之后慢慢的再遇到的都是一些重复性的问题了，当然，还有一些自己没有完全弄明白的问题。如果做的事情是重复的，遇到重复性问题的概率也就会比较多了，如果是在一个新的领域里玩，遇到的问题又都是新的，自己从来没有见过的，但是问题的解决思路基本是类似的。下面这个问题，我觉得值得一记，因为以后还会再遇到类似的，我希望自己能很快的将其解决掉。
2：报错信息
& & &如下是更新项目后，启动项目时抛出的部分错误信息。
十二月 14, :34 下午 org.apache.catalina.core.ContainerBase addChildInternal严重: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652) at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1779) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:618) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:565) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.NoClassDefFoundError: org/springframework/core/env/EnvironmentCapable at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2957) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1210) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1690) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2957) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1210) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1690) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571) at java.lang.Class.getDeclaredFields0(Native Method) at java.lang.Class.privateGetDeclaredFields(Class.java:2499) at java.lang.Class.getDeclaredFields(Class.java:1811) at org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106) at org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:270) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:89) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:63) at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:415) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:892) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:386) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5416) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 40 moreCaused by: java.lang.ClassNotFoundException: org.springframework.core.env.EnvironmentCapable at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571) ... 68 more
十二月 14, :34 下午 org.apache.tomcat.util.modeler.BaseModelMBean invoke严重: Exception invoking method manageAppjava.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:904) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652) at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1779) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:618) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:565) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
3：分析过程
& & &这类问题，我总结过多次，思路每次基本类似。如果是熟悉的，一看就知道哪里出问题了？如果是不熟悉的，就需要好好看看报错信息了，从自己编写的代码中找找出错的地方在哪里？如果也不熟悉，也找不到自己编写的相关代码，只能看看网上有没有其他同学遇到和解决过类的问题了。如果还是找不到问题的所在，就只能麻烦一下身边的同事帮忙看看了，多一个人多一种思路，说不定问题很快就能找到，并解决了。
& & &下面是我对这个问题的分析思路：
3-1：根据引起问题的提示“Caused by: java.lang.ClassNotFoundException: org.springframework.core.env.EnvironmentCapable”，看看能否找到对应的类，如下所示：
3-2：根据上图（3-1）的自我问答，看看我们的项目中依赖的jar文件是否正确，如下所示，确实是存在问题的，随后我们会发现，这个依赖的jar文件中确实没有我们使用的类。
3-3：我们确认一下自己的分析，看看对应的类是否存在于我们依赖的jar文件之中，如下图所示，确实是没有的。
3-4：通过如下图所示的方式，我们到对应的pom文件的依赖处，看看依赖的情况。
3-5：因为传递依赖导致了依赖版本的冲突，我们需要通过exclusion标签排除对应的传递依赖，试试看能否解决对应的问题
3-6：然后我们再次查看项目的依赖，确认我们的项目现在的依赖是没问题的
3-7：重新启动项目后，还是报错，我们只能再次的分析一下这个错误是怎么回事了，思路如上就不在重提了。
3-8：先看看引起错误的类是否存在，如下所示是存在的，不过却是在两个jar文件之中的，这让我首先想到可能还是传递依赖导致的依赖版本有冲突的问题
3-9：根据我们的怀疑，我们就看看我们的项目依赖jar文件是哪个吧！果然，还是低的版本！
3-10：那我们就再次的通过exclusion标签排除一下，试试吧！
3-11：成功了耶！到这里是不是有点小兴奋，毕竟我们的价值多数是源自我们解决的问题！
& & &关于Maven依赖版本冲突的小小分析就结束了，看着比较简单，不过当时自己一步步找问题的时候还是费了一些气力的，在此非常感谢同事Z的提示。现在Maven和Git这两个工具使用的越来越普及了，以后自己在实际的开发中估计会遇到越来越多的和这两个工具相关的问题。慢慢的积累吧！
阅读(...) 评论()