On Tue, Oct 13, 2015 at 10:29 AM, Jason van Zyl <ja...@takari.io> wrote: > >> The second is the ease of messing up. >> >> The maven-release project is set up as a ticking bomb under this >> regime. The project uses dependencyManagement to lock to a version; so >> if any dependency requires a newer version, the result is the >> explosion we have experienced. To me, this seems to call for a >> build-time warning: "You have locked plexus-utils to 3.0.10, but your >> dependency X calls for newer version 3.0.15'. >> >> Is that a thinkable behavior? >> > > Again, you have to know your product. The only holistic view of this is with > the M2Eclipse Dependency Hierarchy View. You can see what versions are > getting managed. You can see what it was and what it has been managed to. If > a change in one dependency indirectly changes another with an incompatibility > then you hoist it up and lock it down. So in this case you may actually want > to hoist plexus-utils up and lock it down to 3.0.10 if it makes everything > work. > > 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. 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.) 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
