commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Maven ids and packages (was: [JCS] release?)
Date Thu, 16 Oct 2014 13:56:49 GMT
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 <sebbaz@gmail.com> wrote:

> On 16 October 2014 14:30, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > 2014-10-16 14:40 GMT+02:00 sebb <sebbaz@gmail.com>:
> >> On 16 October 2014 13:02, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> >>> 2014-10-16 13:48 GMT+02:00 sebb <sebbaz@gmail.com>:
> >>>> On 16 October 2014 09:35, Thomas Vandahl <tv@apache.org> wrote:
> >>>>> On 16.10.14 02:06, sebb wrote:
> >>>>>> On 16 October 2014 00:47, Olivier Lamy <olamy@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message