Once again, thank you Sebb for stepping in and explaining jar hell. It's hellish just explaining it ;-)
Gary On Thu, Oct 16, 2014 at 9:48 AM, sebb <seb...@gmail.com> wrote: > On 16 October 2014 14:30, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > 2014-10-16 14:40 GMT+02:00 sebb <seb...@gmail.com>: > >> On 16 October 2014 13:02, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >>> 2014-10-16 13:48 GMT+02:00 sebb <seb...@gmail.com>: > >>>> On 16 October 2014 09:35, Thomas Vandahl <t...@apache.org> wrote: > >>>>> On 16.10.14 02:06, sebb wrote: > >>>>>> On 16 October 2014 00:47, Olivier Lamy <ol...@apache.org> wrote: > >>>>>>> Perso I don' get the point to use this version number at the end of > >>>>>>> the artifactId > >>>>>> > >>>>>> The idea is that if the package name has to be changed again, i.e. > to > >>>>>> org.apache.commons.jcs2, then the artifactId would become > commons-jcs2 > >>>>>> so that they agree with each other. > >>>>> > >>>>> I consider this rule a bit strict, to be frank. I'd like to think > that > >>>>> the problem of a broken API could be solved differently (by > deliberately > >>>>> renaming API classes for example) but i can live with it for now. > >>>> > >>>> Renaming API classes will break compatibility unless one keeps the old > >>>> classes as well. > >>>> > >>>> Creating new classes and deprecating the old ones is a valid strategy, > >>>> but if one ever wants to get rid of the deprecated classes, it is > >>>> necessary to make a complete break. > >>>> > >>>> It is essential that a given class name only appears in a single Maven > >>>> (groupId,artifactId) pair, otherwise jar hell may result. > >>> > >>> + version + type, having twice the same artifact with different > >>> versions is not correct > >> > >> Not sure about type, but version is not involved here. > >> > > > > That's what I mean. You can't have 2 versions with the same > > gId:aId:type. So no need to change aId. > > I agree you cannot have two such versions on the same class path. > But if the versions are not binary compatible, some apps will fail. > > That is precisely why aId needs changing if the jars are not binary > compatible. > Changing the aid (and package) allows the two jars to co-exist safely. > > >> Maven ensures that only one version of a given (gId,aId) pair is > >> present on the classpath. > >> Once a class is added to a specific version, it must appear in all > >> later versions with the same pair. > >> > >>>> It is also essential that within a Maven pair, classes are not dropped > >>>> between versions (unless the class is not part of the public API) > >>>> otherwise there will be binary compatibility issues. > >>>> > >>> > >>> Main issue is it duplicates a bunch if binaries for free and most of > >>> users could use N+1 without being impacted. > >> > >> No idea what that means. > > > > In TomEE the stack uses [lang], then [lang3] was created and now TomEE > > needs [lang] + [lang3] where actually it only needs [lang] features, > > Then either don't upgrade, or convert TomEE to use only Lang3. > > > ie suppose package didn't change then we wouldn't have had any issue. > > Yes, you would have had an issue. > > If the same class is in lang and lang3 there is no guaranteed way to > ensure the correct version is used. > > That is what jar hell is all about. > > > So it means you tend to import multiple versions of the same lib just > > cause few parts were broken even if it doesn't affect you. That's a > > bit sad IMO. > > > >> > >>> it means this rule is too strict. > >> > >> Why? > >> > >>> Best is to externalize removed binaries in a -compatibility > >>> jar like did maven. It avoids the binary duplication and allow to go > >>> ahead on main stream (IMHO). > >> > >> The later version would not be a drop-in replacement. > >> Sounds like users that needed to use the removed classes would need to > >> add an extra dependency to the POM. > >> > > --------------------------------------------------------------------- > 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
