> On Oct 13, 2015, at 10:45 AM, Benson Margulies <bimargul...@gmail.com> wrote: > >> >> I am just accustomed to seeing the whole graph in M2Eclipse and excluding, >> refactoring and locking things down while I’m running tests. I get >> everything working and then don’t think about much until a required >> dependency change causes something not to work and I track it down again in >> the Dependency Hierarchy View, fix it and carry on. Trying to fix these >> issue without an interactive tool like the Dependency Hierarchy View is >> going to take you 10x longer. It’s really not productive. > > In this case, someone did hoist it up and lock it down. Unfortunately, > someone else then upgraded SCM, and didn't think or know to consider > the possibility that upgrading SCM would result in plexus-utils being > managed down for it. Think about what you are asking people to do: > every time you change the dependency version for some dependency, you > must do a full analysis of the entire dependency tree.
Of course. I do not understand why anyone would update a dependency without understand the impact. I do not randomly update dependencies because of new version of something was released. I generally have all related projects I care about in the IDE, examine the graphs, make sure all the tests work, and use it for a few days in known scenarios. Doing otherwise is fairly negligent. > Absent > universal use of semantic versioning, I appreciate that this is > perhaps inevitable, but I bet that 90% of the commits in the maven > plugins that change a dependency version are not accompanied by this > analysis. (If the tests of the M-R-P had reached this case, we > wouldn't be in this situation.) > Universal semantic versioning is possible with some work, but you’re still never going to know whether a behavioural change negatively affects your project without looking at it. If you have good tests you probably can automate trying new versions of dependencies for a smoke test but there’s no magic here, it’s just work. > I won't go back to Eclipse due to the many awful things that went > wrong for me with it and Maven compared to IntelliJ, however useful > this particular tool might be. I'll be studying the output of mvn > dependency:tree and possibly adding more display to it as needed. > > > >> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Takari and Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> To do two things at once is to do neither. >> >> -- Publilius Syrus, Roman slave, first century B.C. >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Lastly, "Impossible." The lamest of the lame excuses! Difficult maybe, or impractical, or too expensive, but rarely is anything impossible. -- Yvon Chouinard, Let my People Go Surfing --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
