https:\/\/maven.apache.org\/plugins\/maven-dependency-plugin\/<\/a><\/p>\n\n\n\n(mvn dependency:resolve is also very useful, it will show how all dependencies resolve.)<\/p>\n\n\n\n
Effective Poms<\/strong>You can see what is known as an \u201ceffective pom\u201d, which is essentially the pom and every parent all mixed together, also with resolved profiles and any other relevant setting.<\/p>\n\n\n\n
From the commandline you can see the effective pom by running:mvn help:effective-pom<\/code>Generating an effective pom with and without a change and then doing a diff on them can be very helpful – though for dependency issues it is usually helpful when you change to a more recent parent pom and then find things breaking.<\/p>\n\n\n\n
Everything resolves, so what\u2019s the problem?<\/strong>The break is not apparent, you do not get a clear error message saying that you have incompatible library versions. Quite often everything will build, and all unit tests will run – but then if you try to start the service it won\u2019t start. The worst case is sometimes it will start, but eventually you will do something that triggers a call to the incompatible library which fails.<\/p>\n\n\n\n
Example error messages are hard to give as they are fairly random. \u201cNo Such Method\u201d types of errors are common – if the calls to the library changed then calls to the wrong version will give you this error. In general, if you see error messages around calls in a library you aren\u2019t familiar with and didn\u2019t call, then that\u2019s a clue. Googling error messages will often tell you it\u2019s a library mismatch. And sometimes you get a random error and honestly the best thing to do is if you wonder, then remove all your code changes and try running code with just the updated dependencies and see what happens.<\/p>\n\n\n\n
If you see exceptions like these you should be suspicious of a dependency issue:<\/p>\n\n\n\n
\njava.lang.NoSuchMethodError<\/li>\n\n\n\n java.lang.NoSuchMethodException<\/li>\n\n\n\n java.lang.NoSuchFieldError<\/li>\n\n\n\n java.lang.ClassNotFoundException<\/li>\n\n\n\n java.lang.NoClassDefFoundError<\/li>\n<\/ul>\n\n\n\nTo really prove that dependency updates are safe you will need to not only run your unit and integration tests, but actually bring up the service. I have frequently seen dependency upgrades pass all tests, but cause a service to be unable to start.<\/p>\n\n\n\n
Finding the Dependency To Fix<\/strong><\/p>\n\n\n\nIf you have doubts about your dependencies the first step is to isolate the changes. Remove the code changes and just update the pom.This lets you know for sure that the issue is a dependency, and not a code change.<\/p>\n\n\n\n
Now find the pom change that caused the issue. Ideally just apply each pom change one at a time and see if the issue replicates. There might be more than one pom change causing an issue – so you do need to test them all. Honestly I usually do a binary search – put in half the changes and if things work then put in half of the remaining changes and continue.<\/p>\n\n\n\n
This should give you the dependency that is causing the problem, but not which transitive dependency is the actual issue. To find that, remember the command from above:<\/p>\n\n\n\n
mvn dependency:tree -Ddetail=true -Dverbose=true<\/code><\/p>\n\n\n\nRemove the problematic change, and run that command, dumping the output into a file:
Sometimes that\u2019s enough and you can figure it out from there (take a few tries using excludes in the pom file and see!)<\/p>\n\n\n\n
If not, then you might need to find out for sure exactly what is happening in what library. To do that, run the code in IntelliJ and replicate the issue – ideally from a unit test as that\u2019s simpler to bring up, but if you have to run the service then go ahead. Then look at the callstack that failed, and set a breakpoint in it.<\/p>\n\n\n\nSet a breakpoint in that callstack – I usually start with the lowest spot in the codebase (so com.usermind.saiga in the stack above) but often will go lower as well if needed. When I step into the library called from Saiga, look at the project window in IntelliJ:<\/p>\n\n\n\nThat shows me I stepped into Dropwizard-jdbi3 version 2.1.7. Now I can step into that library and just step over lines until something blows up. Next time I will step into the line of code that blew up and repeat. The goal here is watching the project window to the left to see what libraries and versions it is stepping into – that helps me build a picture of what exactly is happening. You will need to write down what is happening with both libraries and versions – because the next step is to revert the code so no dependencies are updated and do the same thing. This gives you a comparison of what libraries it went into when it was working, and what libraries it went into when it failed.<\/p>\n\n\n\n
When you do this there are two things to look for – what library versions do you step into that changed? And also – did the behavior change? If so, why?<\/p>\n\n\n\n
This isn\u2019t something I have to do often, but occasionally it can really help – so don\u2019t be afraid to step into third party code!<\/p>\n\n\n\n
The Toolkit<\/strong><\/p>\n\n\n\nSo you have theories about where the conflict is – so then what?<\/p>\n\n\n\n
The maven dependency commands above will show you which libraries are being pulled in. If you see library A is pulling in library C at version 1, and library B is pulling in library C at version 2 and there is a conflict, try the following steps in order, stopping when the issue resolves.<\/p>\n\n\n\n
IMPORTANT NOTEStep 1<\/strong>: Best Path (but you have to get a little lucky)(Note that \u201cmvn versions:display-dependency-updates\u201d will show you which dependencies can be updated and what the latest version is. \u201cmvn versions:display-plugin-updates\u201d does the same for plugins.)<\/p>\n\n\n\n
Step 2<\/strong>: Exclude the dependent version you don\u2019t want <dependency>\n <groupId>io.dropwizard<\/groupId>\n <artifactId>dropwizard-jersey<\/artifactId>\n <exclusions>\n <exclusion>\n <groupId>commons-logging<\/groupId>\n <artifactId>commons-logging<\/artifactId>\n <\/exclusion>\n <exclusion>\n <groupId>ch.qos.logback<\/groupId>\n <artifactId>*<\/artifactId>\n <\/exclusion>\n <\/exclusions>\n <\/dependency><\/code><\/pre>\n\n\n\nThe first exclusion is to not bring in the commons-logging dependency. But notice the artifact in the second exclusion – it\u2019s a wildcard. That will tell Maven not to bring in any libraries from ch.qos.logback. That is sometimes much simpler than listing out multiple exclusions.<\/p>\n\n\n\n
Step 3<\/strong>: Pick equivalent releasesI have had to do this when there are very closely interconnected dependencies. And I have only had to do this a very few times.<\/p>\n\n\n\n
Step Never<\/strong>: You can include library C yourself at the desired version. Since you included it, it\u2019ll just work! Right? Well \u2026 as long as you picked the right version, sure. I called it step Never because ideally you want to let libraries handle their own dependencies – and now you\u2019ve inserted yourself into that path. So if you update library A you will need to remember to update library C to match.This will cause you major headaches next year when you upgrade library A but have no recollection about Library C. Plus you\u2019re just adding junk into your pom to maintain. So yeah, it\u2019s something you can do, but it isn\u2019t a great way to resolve the issue.<\/p>\n\n\n\nBIG NOTE<\/strong><\/p>\n\n\n\nThis is never easy. I will often keep making changes and excluding libraries and just trying things until I get something that works – if it’s a minor conflict then no big deal, but wait until you have four libraries that all have to be at equivalent versions and all of which bring in a set of conflicting dependencies …<\/p>\n\n\n\n
So when I get something working, sometimes there is a mess. Most likely the last change is the one that worked, so go back and start rolling out the prior changes. If it didn’t help, then it shouldn’t get checked in. Just pick a set of changes, comment them out, and test. If things still work, but another set of changes and repeat. Just don’t check in all the false paths you tried, it’s just adding more complications that will cause you a headache later!<\/p>\n\n\n\n
Conclusions<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
For when you get a small task to update some Maven dependencies and then two weeks later find yourself explaining to your manager what a Sisyphean Task is <\/p>\n","protected":false},"author":1,"featured_media":921,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[26],"tags":[27],"_links":{"self":[{"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/posts\/924"}],"collection":[{"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/comments?post=924"}],"version-history":[{"count":8,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/posts\/924\/revisions"}],"predecessor-version":[{"id":943,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/posts\/924\/revisions\/943"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/media\/921"}],"wp:attachment":[{"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/media?parent=924"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/categories?post=924"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.evan.org\/ghg\/wp-json\/wp\/v2\/tags?post=924"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/regret.gif\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/POM-Updates.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/DepTree.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/DepTreeVerbose.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/DepTreeIntelliJ.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/DepCallstack-1024x315.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.evan.org\/ghg\/wp-content\/uploads\/2023\/07\/DepCallstackIntelliJ.png\")
<\/figure>\n\n\n\n