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