Benson Margulies <bimargul...@gmail.com> schrieb am Fr., 3. Juni 2016 um 00:43 Uhr:
> Just to cite a fact: > > If you write: > > <dependencyManagement> > <dependencies> > <dependency> > ... > <version>x</version> > ... > > You will get x. Even if transitive dependencies ask for x+10. I only > learned this recently. > Yes thats true. Coming back to our example you could specify: My-Project | -> A -> B -> C 1.2 | -> D -> C 2.0 | -> C 1.2 Maven will use the dependency which is closest to the project root. So in the first example C 2.0 was closed. Now we have defined a direct dependency to C 1.2. maven will use this one instead. But what do you win by this? Your app is still broken. This is a problem you can't resolve in your pom. This is the reason we're changing maven and package coords so you can have both versions. Benedikt > > > On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers <ralph.go...@dslextreme.com> > > wrote: > > > >> Dependency management does not cure this if C 1.2 and C 2.0 are not > binary > >> compatible. Code compiled with the 1.2 version will fail if those > methods > >> and classes are not in 2.0. > >> > > > > Indeed, hence the BC break -> Maven Coord change requirement. > > > > Gary > > > > > >> Ralph > >> > >> > On Jun 2, 2016, at 3:03 PM, Benson Margulies <bimargul...@gmail.com> > >> wrote: > >> > > >> > Dependency management cures this; if you don't want to pick up newer > >> > versions, you can prevent it. Since dep management doesn't know about > >> > ranges or semantic versioning, you need to then pay attention if you > >> > want a compatible version that comes along. > >> > > >> > I guess it's a question of which poison you prefer. If people here > >> > prefer bumping artifactids and package names, so be it. > >> > > >> > > >> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <brit...@apache.org> > >> wrote: > >> >> Hello Benson, > >> >> > >> >> Benson Margulies <bimargul...@gmail.com> schrieb am Do., 2. Juni > 2016 > >> um > >> >> 23:36 Uhr: > >> >> > >> >>> I don't understand what's wrong with semantic versioning and keeping > >> >>> the same maven coordinates. No sane person should be using RELEASE > or > >> >>> LATEST. > >> >>> > >> >> > >> >> The problem are transitive dependencies. Consider this example: > >> >> > >> >> My-Project > >> >> | -> A -> B -> C 1.2 > >> >> | -> D -> C 2.0 > >> >> > >> >> In this case my project depends directly on A and D. A depends on B > >> which > >> >> depends on C in version 1.2. D depends on C in version 2.0. In this > >> case I > >> >> have no control over the dependencies to C but my project will be > >> broken at > >> >> run time, because C 1.2 and C 2.0 can not exist at once in the same > >> >> classpath. > >> >> > >> >> Benedikt > >> >> > >> >> > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>> > >> >>> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > Java Persistence with Hibernate, Second Edition > > <http://www.manning.com/bauer3/> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
