解决maven冲突难题,告别jenkins打包失败及jar包冲突检测困扰

检测维修 0 20

你能够借助maven, 这一堪称优秀的项目管理工具, 轻松地去定义一个引用, 以此达成使用他人所编写好的库的功效。并且, 借助maven能够极为轻松地与jenkins展开配合, 进而让打包部署这一操作变得更为轻松容易。

然而正因此, 我们变得愈发傻气痴笨了,以至于有时竟忘掉了一些原本的、基础的办法, 当然这并非本文的意图, 本文的意图是, 怎样去处理一些maven所引发的冲突难题。

问题1: jenkins进行打包操作遭遇失败状况, 致使我没办法将代码安装到测试环境当中, 该如何处理呢?

回应称: 通常情况下而言, 借助jenkins去开展某些额外的改动, 以此来契合公司内部的要求, 或者对一些经过微调的事物实行优化。 然而鉴于jenkins自身仍旧比较繁杂的缘故, 偶尔这是避免不出现我们弄不分明它的运行原本道理的状况的, 进而致使一些无法实现打包的状况出现。当然, 我这边所碰到的问题, 通常是源于jenkins的缓存机制引发的状况 , 所以, 在我本地能够进行打包的代码 , 放置到jenkins上却压根打不了包 , 因为我所依赖的一个jar包 , 因被jenkins缓存了一个老版本的包 , 里面不存在我新的内容进而致使打包失败 ,看上去短时间内没办法处理这个缓存问题。

于是, 我借助本地的ide工具打好war包, 之后将其上传至服务器的tomcat目录, 在等待tomcat自动部署完成后重新启动新代码, 进而绕过了jenkins失败的问题。

若是针对jar包而言, 便会显得更为便利, 能够直接于本地生成jar包, 接着替换服务器上的相应包, 然后重启服务就可以达成。

综上所述, 此处的解决方案为, 一旦工具出现故障, 我们便不可再依赖工具, 需回归到初始状态去解决问题。

问题2: 在我们对代码-war/jar进行运行这项操作之后, 出现报某一个方法没被找到这种情况, 也就是呈现出java.lang.NoSuchMethodError:这样的报错信息, 当我们仔细去查看代码的时候, 实则是存在该方法的, 这种情形该如何去进行排查呢?

答: 针对这个问题, 通常状况下是鉴于引入了多个具备相同功能的jar包, 并且包路径全然一样, 而在类加载器进行加载的时候, 有可能会加载到你并不希望加载的类, 进而致使不存在该方法。

解决的办法是, 将并非属于自身的引用予以删除, 借此达成运用自身想法的类。在maven当中呈现为排除某一依赖, 就像:

       <dependency>
            <groupId>com.xx.activitygroupId>
            <artifactId>abcartifactId>
            <version>2.0.13-SNAPSHOTversion>
            <classifier>dubboclassifier>
            <exclusions>
                <exclusion>
                    <groupId>com.meidusa.venusgroupId>
                    <artifactId>venus-backendartifactId>
                exclusion>
            exclusions>
        dependency>

maven冲突问题_jar包冲突检测工具_jenkins打包失败解决方法

可是, 存在着另外一个棘手难题, 具体而言, 究竟怎样能够查找到究竟是引用了哪一个指定的安装包, 进而引发了冲突状况呢? 毕竟依据你所查看的本地代码, 可以说是不存在任何一点异常情况迹象的。

我们能够直接去搜索有关整个包的引用, 并且将其中所含的代码解开, 进而查看冲突的类, 冲突方法比较难以查找出来, 当然, 是直接于服务器上展开查找的。

find . -name '*.jar' -exec jar -tvf {} \; | grep EE   # 即找出所有的jar包,再解压出其文件列表,再搜索冲突的类名

如果有发现两个相同的结果,那么就是冲突了,解决该冲突即可。

当然了, 要是引入的jar文件数量不多, 或者你对于基本方向存在哪个包发生冲突的怀疑, 那么, 径直把该包下载下来, 选用反编译工具(像是jd - gui)进行编译从而得出结果, 查看它的内部状况, 如此一来也就清楚明白了句号。

问题3: 发觉tomcat启动异常迅速, 且诸多加载流程都未出现, 便径直启动了, 实际上各个理应存在的服务皆不存在, 这种情况该如何进行排查呢?

答: 这种问题颇有些缺乏头绪, 解决起来大体上也全依仗运气。此处tomcat看似正常启动过, 然而实际上众多事务未开展、未加载。换个角度来讲, 则是加载出现了中断。最为棘手的是日志里压根不会给出任何信息。通常能够先从代码的改动之处着手排查, 将以一段一段代码还原的方式当作主要排查手段。

有那么一个特别关键的问题存在, 那就是, 你引用了一个jar包,其jdk版本比你自身运行环境要高, 依照jvm的加载原理, 它会先去检查class文件的版本号, 要是高于自己能够加载的版本, 如此, 它就会直接拒绝加载, 并且不会去检查该class文件是否引用了一些不认识的特性。倘若jvm不加载类了, 那么你后续流程就没办法进行了。

要是的确是因jar包版本造成的那种问题, 那, 问题就易于解决了。其一, 要么让给你供给jar包的那位同学把其拿去打包之时所采用的jdk版本降低, 降至你所需要的版本便可。其二, 提升自身的jvm运行环境, 进行jdk的升级, 当然, 这般做可能会存在风险, 要慎之又慎行事。

上述表达内容, 是关于很小部分问题排查所得到的心得体会, 聊作心底安慰。同时, 也期盼自己对于存在有着相同一类问题的同学们指点一个导向。

碰到问题之际, 我们常常如此处理, 一个问题, 或许历经数日都未必能够解决, 然而等到切实解决之时, 发觉实则极为简单, 而后, 说不定下一回, 又再度重复这般状况!

相关推荐: