Maven ids and packages (was: [JCS] release?)

[sebb <se...@gmail.com>]

On 16 October 2014 14:30, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 2014-10-16 14:40 GMT+02:00 sebb <se...@gmail.com>:
>> On 16 October 2014 13:02, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>> 2014-10-16 13:48 GMT+02:00 sebb <se...@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 <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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Maven ids and packages (was: [JCS] release?)

[Gary Gregory <ga...@gmail.com>]

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 <se...@gmail.com> wrote:

> On 16 October 2014 14:30, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> > 2014-10-16 14:40 GMT+02:00 sebb <se...@gmail.com>:
> >> On 16 October 2014 13:02, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >>> 2014-10-16 13:48 GMT+02:00 sebb <se...@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 <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-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