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.
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
