关于jar包版本依赖冲突问题如何解决，求教大神
现在有3各独立的工程，各自生成jar包（A, B, C），先出现如下依赖关系，看看如何解决：
A 拥有1.0和2.0两个版本，这两个版本存在不兼容
B 依赖于A的1.0版本
C 依赖于B和A的2.0版本
目前分析肯定是C要依赖B和A的2.0版本，B要依赖A的1.0版本，这样A的jar包冲突，请教大神有没有好的办法解决或者规避这个问题？？
最好的办法是修改B依赖于A 2.0，或者将A的不同版本用不同的package路径区别开来，否则在普通环境下几乎无法解决这种依赖同一jar包不同版本的情况。
另外一种解决方案是使用osgi框架，能完美解决不同版本依赖的问题，但是你的整个应用需要移植到osgi框架中。难度和复杂度较高。
--- 共有 2 条评论 ---
感谢提供了一个很好的思路
看了一下osgi确实麻烦，是不是做高版本向下兼容，替换版本的话直接换包路径就可以了？
用maven解决
--- 共有 1 条评论 ---
谢谢，有各疑问，maven会依赖A的最高版本，也就是2.0版本，那运行的时候B的jar包还是报冲突了，因为B依赖的是1.0
maven exclusion去掉一个冲突的，用idea或者eclipse插件看一下冲突的jar
--- 共有 1 条评论 ---
谢谢，貌似还是不能解决，去掉冲突的总有一个运行不起来Maven怎么处理引用的jar版本冲突？ - maven - ITeye群组
& 上一页 1
我找到的个项目 AAA的，但是用的是lucene3.0. 而我们现在的工程BBB里面已经用了lucene2.9-----我们的项目用这个AAA怎么处理lucene冲突啊?
&dependency&& &artifactId&aaa&/& &exclusions&&&& &exclusion&&&&&& &artifactId&lucene&/...
同一个artifactId，maven只会加载版本高的jar。不研究过，不十分确定这样的机制。
有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
peizhyi 写道有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
首先在 自己的 pom 中，人为不可能引入两个版本不同的依赖。冲突最可能的就是你依赖的依赖可能产生了冲突。
比如 A 依赖 版本为2.0 的 C ,B 依赖 版本为3.0的 C。在你的pom中，你同时依赖了 A 和 B ，这时就会产生冲突。这时候你就要判断，哪个版本能同时让A和B工作(如果可以的话)，然后排除掉另一个就行了。我通常都是排除掉较低的版本。
&dependencies&
&dependency&
&groupId&A&/groupId&
&artifactId&A&/artifactId&
&version&xxx&/version&
&exclusions&
&exclusion&
&groupId&C&/groupId&
&artifactId&C&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&dependency&
&groupId&B&/groupId&
&artifactId&B&/artifactId&
&/dependency&
&/dependencies&
bastengao 写道peizhyi 写道有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
首先在 自己的 pom 中，人为不可能引入两个版本不同的依赖。冲突最可能的就是你依赖的依赖可能产生了冲突。
比如 A 依赖 版本为2.0 的 C ,B 依赖 版本为3.0的 C。在你的pom中，你同时依赖了 A 和 B ，这时就会产生冲突。这时候你就要判断，哪个版本能同时让A和B工作(如果可以的话)，然后排除掉另一个就行了。我通常都是排除掉较低的版本。
&dependencies&
&dependency&
&groupId&A&/groupId&
&artifactId&A&/artifactId&
&version&xxx&/version&
&exclusions&
&exclusion&
&groupId&C&/groupId&
&artifactId&C&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&dependency&
&groupId&B&/groupId&
&artifactId&B&/artifactId&
&/dependency&
&/dependencies&
比较让人郁闷的问题是，用了2.0的缺方法一，用了3.0的缺方法二。。这种问题还有解吗？
那这就是硬伤了
peizhyi 写道bastengao 写道peizhyi 写道有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
首先在 自己的 pom 中，人为不可能引入两个版本不同的依赖。冲突最可能的就是你依赖的依赖可能产生了冲突。
比如 A 依赖 版本为2.0 的 C ,B 依赖 版本为3.0的 C。在你的pom中，你同时依赖了 A 和 B ，这时就会产生冲突。这时候你就要判断，哪个版本能同时让A和B工作(如果可以的话)，然后排除掉另一个就行了。我通常都是排除掉较低的版本。
&dependencies&
&dependency&
&groupId&A&/groupId&
&artifactId&A&/artifactId&
&version&xxx&/version&
&exclusions&
&exclusion&
&groupId&C&/groupId&
&artifactId&C&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&dependency&
&groupId&B&/groupId&
&artifactId&B&/artifactId&
&/dependency&
&/dependencies&
比较让人郁闷的问题是，用了2.0的缺方法一，用了3.0的缺方法二。。这种问题还有解吗？
同求啊。发生了同样的问题。 两个版本，高版本不兼容低版本的方法。目前的方案有两个 。一个是把其中的一个版本的maven坐标更换了，让两个都加载。不过还没有验证过。应该也会有问题。另外一个方法就是把低版本的包路径全部更换，再更换低版本的maven坐标，防止冲突。但是这些方法太繁琐，而且感觉不靠谱呀！有没有更好的方法解决？
cosmo1987 写道peizhyi 写道bastengao 写道peizhyi 写道有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
首先在 自己的 pom 中，人为不可能引入两个版本不同的依赖。冲突最可能的就是你依赖的依赖可能产生了冲突。
比如 A 依赖 版本为2.0 的 C ,B 依赖 版本为3.0的 C。在你的pom中，你同时依赖了 A 和 B ，这时就会产生冲突。这时候你就要判断，哪个版本能同时让A和B工作(如果可以的话)，然后排除掉另一个就行了。我通常都是排除掉较低的版本。
&dependencies&
&dependency&
&groupId&A&/groupId&
&artifactId&A&/artifactId&
&version&xxx&/version&
&exclusions&
&exclusion&
&groupId&C&/groupId&
&artifactId&C&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&dependency&
&groupId&B&/groupId&
&artifactId&B&/artifactId&
&/dependency&
&/dependencies&
比较让人郁闷的问题是，用了2.0的缺方法一，用了3.0的缺方法二。。这种问题还有解吗？
同求啊。发生了同样的问题。 两个版本，高版本不兼容低版本的方法。目前的方案有两个 。一个是把其中的一个版本的maven坐标更换了，让两个都加载。不过还没有验证过。应该也会有问题。另外一个方法就是把低版本的包路径全部更换，再更换低版本的maven坐标，防止冲突。但是这些方法太繁琐，而且感觉不靠谱呀！有没有更好的方法解决？
现在想想看，有一个方法相对可行。把应用这两个版本不同方法的部分，拆成两个子项目，两个子项目各自引用不同版本的包。这样就能够同时引用，也不会冲突。
peizhyi 写道cosmo1987 写道peizhyi 写道bastengao 写道peizhyi 写道有同样的问题，当项目中依赖的两个包版本不一致的时候出现问题，我用的包是com.google.protobuffer，2.1和2.3冲突，用了一楼的做法，没有效果呀。
首先在 自己的 pom 中，人为不可能引入两个版本不同的依赖。冲突最可能的就是你依赖的依赖可能产生了冲突。
比如 A 依赖 版本为2.0 的 C ,B 依赖 版本为3.0的 C。在你的pom中，你同时依赖了 A 和 B ，这时就会产生冲突。这时候你就要判断，哪个版本能同时让A和B工作(如果可以的话)，然后排除掉另一个就行了。我通常都是排除掉较低的版本。
&dependencies&
&dependency&
&groupId&A&/groupId&
&artifactId&A&/artifactId&
&version&xxx&/version&
&exclusions&
&exclusion&
&groupId&C&/groupId&
&artifactId&C&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&dependency&
&groupId&B&/groupId&
&artifactId&B&/artifactId&
&/dependency&
&/dependencies&
比较让人郁闷的问题是，用了2.0的缺方法一，用了3.0的缺方法二。。这种问题还有解吗？
同求啊。发生了同样的问题。 两个版本，高版本不兼容低版本的方法。目前的方案有两个 。一个是把其中的一个版本的maven坐标更换了，让两个都加载。不过还没有验证过。应该也会有问题。另外一个方法就是把低版本的包路径全部更换，再更换低版本的maven坐标，防止冲突。但是这些方法太繁琐，而且感觉不靠谱呀！有没有更好的方法解决？
现在想想看，有一个方法相对可行。把应用这两个版本不同方法的部分，拆成两个子项目，两个子项目各自引用不同版本的包。这样就能够同时引用，也不会冲突。
拆成两个子项目，如果是指maven项目下的两个module的话，最后构建maven的web项目时两个module所依赖的jar会打包到一个war中。问题没有解决。而如果是指两个maven项目并且分别部署的话，这样仅仅为了隔离jar依赖而拆项目，这个项目也不好拆。毕竟拆项目的依据还是在当一个应用过大，需要降低耦合划分成两个子系统的时候才需要做。之前又想到两个解决方案。不过还有待权衡。1.引入OSGI架构。架构的引入可以很好的以组件的形式可插拔的更换模块，并且可以很好的做到jar隔离。但是OGSI的引入又会带来很多其他的麻烦。学习成本增加，OSGI的引入必然带来整个项目结构的变动，而且引入OSGI后，所有的模块都必须以OSGI的方式进行，对于一些觉得很简单且没有必要使用OSGI方式编写的代码，不能被OSGI引用。2.自己实现web container下一级的application classloader。对于一些特殊的jar使用配置的方式让自己实现的classloader进行加载。在classloader这一层做到隔离后的jar相互调用问题。这个classloader的实现确实是一个技术活。需要解决很多问题。开发成本提高很多。目前为止还是没有想出简单方便的方法解决这个问题。
& 上一页 1博客访问： 2032261
博文数量： 187
博客积分： 613
博客等级： 中士
技术积分： 5415
注册时间：
认证徽章：
人, 既无虎狼之爪牙,亦无狮象之力量,却能擒狼缚虎,驯狮猎象,无他,唯智慧耳。
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： HADOOP
& & &一个上午自己都在调试，昨天调到了85行左右，今天貌似也没有前进多少，但是也解决了不少新问题。首先回到昨天的问题，昨天下午困扰自己的问题是提示slf4j-api的版本不兼容问题，提示需要1.6.x以上的slf4j才可以。自己更新了hbase/lib/下的slf4j的jar包，但是问题依旧，昨天暂时卡在了这里。今天早上自己继续搜索资料的时候，无意间发现一个类似的问题是通过修改hadoop/lib/下的slf4j的包实现的，自己猛然想到也许hadoop下也有类似的包。果然，立刻修改更新hadoop/lib/下的slf4j相关的jar包，统一升级到1.6.6。以下是昨天的问题：
& & &自己将slf4j-api-1.6.6.jar和slf4j-log4j12-1.6.6.jar添加到/hadoop/lib和/hbase/lib下，注意不要添加slf4j-jdk14-1.6.6.jar，否则会爆multiple bindings错误。完成这一步之后终于跨过了slf4j版本的问题，但是竟然又出现了新问题：
& & &从控制台来看，大量的INFO信息，唯一可能是错误原因的是这么一句：
INFO zookeeper.ClinetCnxn:Opening socket connection to server localhost/127.0.0.2:2181.& Will not attempt to authenticate using SASL(Unknown error)
& & &于是自己查找这个提示的相关信息，所得的资料都是关于DNS解析错误导致的问题，和自己的问题都不相同。自己就想既然是Zookeeper的问题为什么没有日志呢？去hbase/logs下查看只有hbase-hadoop-master-*和regionserver的日志信息。自己查看conf/目录发现了log4j.properties文件，直觉告诉自己这应该是hbase日志输出相关的配置文件，打开之后果然如己所料。分析之后也发现了没有zookeeper日志的原因，因为默认zookeeper是不将日志输出到文件的。于是自己又上网查找资料来重新修改配置文件：
#doop@hadoop:~/platform/hbase-0.94.9/logs Define some default values that can be overridden by system properties
hbase.root.logger=ERROR,console,fileout
hbase.security.logger=ERROR,console,fileout
hbase.log.dir=.
hbase.log.file=hbase.log
# Define the root logger to the system property "hbase.root.logger".
log4j.rootLogger=${hbase.root.logger}
# Logging Threshold
log4j.threshold=ALL
log4j.appender.fileout=org.apache.log4j.RollingFileAppender
log4j.appender.fileout.target=/home/hadoop/platform/hbase-0.94.9/logs/zookeeper.log
log4j.appender.fileout.layout=org.apache.log4j.PatternLayout
log4j.appender.fileout.layout.ConversionPattern=%d{ISO8601} %p %c: %m%n
# Daily Rolling File Appender
log4j.appender.DRFA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.DRFA.File=${hbase.log.dir}/zookeeper.log
log4j.appender.DRFAS.layout=org.apache.log4j.PatternLayout
log4j.appender.DRFAS.layout.ConversionPattern=%d{ISO8601} %p %c: %m%n
# Rollver at midnight
log4j.appender.DRFA.DatePattern=.yyyy-MM-dd
# 30-day backup
#log4j.appender.DRFA.MaxBackupIndex=30
log4j.appender.DRFA.layout=org.apache.log4j.PatternLayout
# Pattern format: Date LogLevel LoggerName LogMessage
log4j.appender.DRFA.layout.ConversionPattern=%d{ISO8601} %p %c: %m%n
# Debugging Pattern format
#log4j.appender.DRFA.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} (%F:%M(%L)) - %m%n
# Security audit appender
hbase.security.log.file=SecurityAuth.audit
log4j.appender.DRFAS=org.apache.log4j.DailyRollingFileAppender
log4j.appender.DRFAS.File=${hbase.log.dir}/${hbase.security.log.file}
log4j.appender.DRFAS.layout=org.apache.log4j.PatternLayout
log4j.appender.DRFAS.layout.ConversionPattern=%d{ISO8601} %p %c: %m%n
log4j.category.SecurityLogger=${hbase.security.logger}
log4j.additivity.SecurityLogger=false
#log4j.logger.SecurityLogger.org.apache.hadoop.hbase.security.access.AccessController=TRACE
# Null Appender
log4j.appender.NullAppender=org.apache.log4j.varia.NullAppender
# Add "console" to rootlogger above if you want to use this
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.target=System.err
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d{yy/MM/dd HH:mm:ss} %p %c{2}: %m%n
# Custom Logging levels
log4j.logger.org.apache.zookeeper=ERROR
#log4j.logger.org.apache.hadoop.fs.FSNamesystem=DEBUG
log4j.logger.org.apache.hadoop.hbase=ERROR
# Make these two classes INFO-level. Make them DEBUG to see more zk debug.
log4j.logger.org.apache.hadoop.hbase.zookeeper.ZKUtil=ERROR
log4j.logger.org.apache.hadoop.hbase.zookeeper.ZooKeeperWatcher=ERROR
#log4j.logger.org.apache.hadoop.dfs=DEBUG
# Set this class to log INFO only otherwise its OTT
# Uncomment this line to enable tracing on _every_ RPC call (this can be a lot of output)
#log4j.logger.org.apache.hadoop.ipc.HBaseServer.trace=DEBUG
# Uncomment the below if you want to remove logging of client region caching'
# and scan of .META. messages
# log4j.logger.org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation=INFO
# log4j.logger.org.apache.hadoop.hbase.client.MetaScanner=INFO
& & & 我们需要修改的其实只有几个位置：
1. hbase.root.logger=ERROR,console,fileout
& & &设置日志记录的事件等级，当然可以使用INFO，后面是两种记录方式，一种是控制台，一种是fileout，二者其实都是变量名，需定义
2. 由于默认控制台输出，所以这里只来配置文件日志输出：
log4j.appender.fileout=ort.appache.log4j.RollingFileAppender & & &//注释要删掉：定义fileout变量绑定自动增长性文件
log4j.appender.fileout.target=YoutDir-log
log4j.appender.fileout.layout=org.apache.log4j.PatternLayout & & &//日志布局
log4j.appender.fileout.layout.Conversionpattern=%d[ISO8601] %p %c: %m%n &//记录格式
3. 在指定目录下手动建立zookeeper.log文件，修改保存配置文件后重新启动hbase
& & &问题依旧，但是我们可以查看生成的zookeeper.log日志：
& & &可以看到错误提示：regionserver.metrics.SchemaMetrics: Inconsistent configuration. Previous configuration for using talbe name in metric: true, new configuration: false。今天自己暂时卡在了这一步，上网去查也没有相关的资料，直接提示regionserver的问题，可是自己设定的是本机啊，到底问题出在哪里呢？
阅读(8638) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。Eclipse下jar包版本不一致等常见问题 - cantellow - ITeye技术网站
博客分类：
我借这个平台简单说说Eclipse下配置环境需要注意的几点，大多数情况下，我们遇到最多的根源就是jar包的版本不一致，比如我调用某个类的方法，这个方法在旧版本其实不存在的，这时候编译不会通过，这种情况还是好的，至少它明确告诉你哪个类存在问题，进而我们可以找到这个类所属的jar包。最要命的是程序运行时出现这种情况，那你肯定会问为什么编译的时候能通过，想一下远程调用，客户端是怎么调用服务器端的对象的，对象时怎么传输的，这一切都可能用到序列化，对于序列化来说，每个类都有一个版本，何止是jar包，当java从硬盘还原为一个对象时，你除了保证这个类的定义在客户端和服务端都存在，而且还要保证它们的版本都要一致，这种问题编译时期是检查不出来的。
除了jar包版本的问题，还有一类的问题也比较常见，那就是工程和jar包引用的顺序，Eclipse通过classpath来定义类的引用关系，通常，我们用的最多的是源代码，源码工程，jar包，它们的顺序很重要，这也是导致jar包版本不一致的一个原因，想象一下，目的工程依赖A工程和B jar包，同时A工程也依赖B jar包，当然也引用了它，那么目的工程到底去寻找直接引用的B jar包呢还是引用A工程依赖的jar包？这三者之间的顺序有关系，我不建议你凭感觉行事，最有效的办法就是设置在B jar包的入口处设置一个断点，看它到底依赖的是哪个jar包。
很多工程都有配置文件，拿我们公司的来说，客户端有启动顺序xml配置文件，服务器端有服务器服务xml配置文件，有没有想过再Eclipse环境下是按什么方式找这些配置文件的，它查找目录的顺序又是怎样的？如果这些配置定义重复了会不会有问题？我就遇到过这样一种情况，A客户端定义了一份启动配置文件xml，平台客户端定义了一份启动配置文件xml，A客户端依赖平台客户端，最后它找到了两份启动配置文件xml，每一个task任务都重复加了一次，导致客户端启动出现问题。
说了上面三点我们经常遇到的问题根源，那么我再说说解决jar包版本问题不一直的最佳途径，首先，你要对哪些工程依赖哪些包，而这些包又是干什么的要熟悉，然后，将这些jar包都整理成一个版本统一放在一个文件夹下，然后将Eclipse的wokespace下工程依赖的jar包都指向这个文件夹下，保证整个wokespace下面用到的jar包都是同一个jar包。然后，建立工程，最重要的一点是，整个过程保持头脑十分清晰，不要犯低级错误，否则你会疲于奔命，而且，你做的每一个操作你必须要给出足够的理由。第一阶段是编译器通过，保证不会出现编译错误，第二阶段就是程序运行正常，这一阶段通常都是程序启动时会遇到很多问题，这种问题最霸道的解决办法就是深入代码！不要觉得这是一个小问题，深入代码可能会浪费你很多时间，你错了，如果你不深入代码，仅仅凭感觉操作的话，你会浪费十倍的时间！
浏览: 527983 次
来自: 草帽海贼团
第三种稍微有点Java基础就知道是错的，被瞎写误导别人，复制粘 ...
第四种，静态方法中是不能用this的吧。。
这样的：&div class=&quote_t ...
还有一种利用JVM的类加载机制，
它是线程安全的，同时又是在用 ...
第四种有问题