commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [JCS] release?
Date Thu, 16 Oct 2014 12:40:16 GMT
On 16 October 2014 13:02, Romain Manni-Bucau <> wrote:
> 2014-10-16 13:48 GMT+02:00 sebb <>:
>> On 16 October 2014 09:35, Thomas Vandahl <> wrote:
>>> On 16.10.14 02:06, sebb wrote:
>>>> On 16 October 2014 00:47, Olivier Lamy <> 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.


> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message