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. > 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, ie suppose package didn't change then we wouldn't have had any issue. 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. > >>>> Bye, Thomas. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> > > --------------------------------------------------------------------- > 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
