Hi Niranjan, > We do set this because we have been burned many times where wrong > classes from older jar files were getting loaded. ... > This caused all sort of interesting crashes at runtime.
Runtime... of your application? That would be caused by your deployment mechanism, which is past where Maven is involved. How do you generate your final application? How is it decided what gets included on your classpath? Or do you mean that the wrong dependency JAR(s) are selected at compile time by Maven? Personally, I do not see the value in enforcing dependency convergence. In practice you are going to continually run into problems where you depend on components A and B and they each depend on a different version of C... and then what? Lots of exclusions? Much easier if you can just let Maven pick the newest. My strong suggestion would be to understand exactly the root cause of your previous issue, and find out how to solve it without using this enforcer rule. Or maybe someone else who uses this rule can comment further on its intended use, and a way to achieve what you want. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software On Wed, Nov 23, 2016 at 6:25 PM, Niranjan Rao <nhr...@gmail.com> wrote: > Hi Curtis, > > Sorry for the late reply. > > We do set this because we have been burned many times where wrong classes > from older jar files were getting loaded. For most part this is ok, but if > memory serves right, we faced few problems with spring/hibernate where it's > internal dependencies conflicted with some other dependencies. This caused > all sort of interesting crashes at runtime. > > I am not sure and it was long time (couple of years) back, but I think > root cause was wrong type of proxy class getting created and dependencies > not getting injected correctly. > > Regards, > > Niranjan > > On 11/19/2016 01:09 PM, Curtis Rueden wrote: > >> Hi Niranjan, >> >> I have set maven enforcer plugin with dependency convergence. >>> >> Naive question: why do this? One of the (IMHO) great things about Maven is >> that it resolves conflicting dependency versions in a generally desirable >> way. As long as the newer version of the dependency is backwards >> compatible >> with the old at runtime, there should be no problem. The only issue is >> when >> there are backwards incompatibilities, no? But in the case of >> websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer >> version, >> which means it should be backwards compatible, right? >> >> Regards, >> Curtis >> >> -- >> Curtis Rueden >> LOCI software architect - http://loci.wisc.edu/software >> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden >> >> >> On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao <nhr...@gmail.com> wrote: >> >> Greetings, >>> >>> I have set maven enforcer plugin with dependency convergence. Usually I >>> solve these errors with exclusion entries. >>> >>> With recent upgrade to selenium 3.0.1 I am getting dependency convergence >>> error that I am not sure how to resolve. It's selenium-java that has two >>> conflicting dependencies. If I add exclusion entry, I'll have most >>> probably >>> will have to add the required dependencies myself and might break future >>> upgrades and/or increase maintenance work. >>> >>> >>> Dependency convergence error for org.eclipse.jetty.websocket:we >>> bsocket-client:9.2.18.v20160721 paths to dependency are: >>> +-mygroupId:artifact:4.0-SNAPSHOT >>> +-org.seleniumhq.selenium:selenium-java:3.0.1 >>> +-net.sourceforge.htmlunit:htmlunit:2.23 >>> +-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721 >>> and >>> +-mygroupId:artifact:4.0-SNAPSHOT >>> +-org.seleniumhq.selenium:selenium-java:3.0.1 >>> +-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210 >>> >>> Regards, >>> >>> Niranjan >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
