commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: AW: [math] roadmap for 2.X and 3.0 ?
Date Wed, 24 Nov 2010 17:57:23 GMT
Le 24/11/2010 18:44, sebb a écrit :
> On 24 November 2010 17:01, Luc Maisonobe <> wrote:
>> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>>> that depends on math 2.1.  Orekit itself (or whatever other immediate
>>>> dependency) may not have cut a release changing its internal use to 3.0.
>>> Is this realistic? I would expect quite early an Orekit version supporting CM
>>> 3.0.
>> For Orekit, you are right, we will be 3.0 ready very early but it is a
>> somewhat ideal situation: the same people are involved in both tools.
>> Also in the example situation I presented, the problem is in fact the
>> other way round: Orekit will switch to 3.0 much earlier than the top
>> level project. This does not change the problem, though: in both cases
>> we have two libraries that need two different versions, their relative
>> ordering is irrelevant.
>>> May be not a release but the actual Orekit trunk. So for your own release you
>>> would have to wait for the next Orekit release which is CM 3.0 compatible.
>>> But in the meantime you can still test your CM 3.0 compatible stuff - by using
>>> a not yet officially released Orekit version.
>>> Are there projects where such a procedure is not acceptable?
>> There are operational projects that are not allowed to rely on
>> unpublished versions. The intermediate libraries may also be
>> closed-source and people may simply not want to buy new versions too
>> often. So they would have to wait for an official release of
>> commons-math, then an official release of ALL the libraries that depend
>> on commons-math, then they could start upgrading themselves. As some
>> libraries may well be stable enough to not require publishing a new
>> version, that would condemn their users to stick to commons-math 2.x for
>> a long time.
>> This is one classical situation for jar hell: project A uses components
>> B1 and B2 and both components use a low level C component. A bug is
>> discovered in C and it is a major one for B1. Then a new version of C is
>> published, followed by a new version of B1 that depends on it. However
>> B2 is not affected by this bug and is a stable component: it does not
>> update its use of C and still rely on the old version with the bug.
>> Project A is in jar hell.
> It's only in jar hell if C2 is not binary compatible with C1 (and then
> only if B2 uses the part of C1 that changed in C2)

Yes, sorry, the example was not complete.

thanks for the clarification

> Otherwise, surely just replace C with Cv2 and both B1 and B2 are happy?
> If C1 and C2 have the same Maven gid:aid combination, only C2 willl be
> put on the classpath.
>> The situation is worse if B2 is not an
>> open-source project, as project A really cannot make the change by itself.
>> Luc
>>> ---------------------------------------------------------------------
>>> 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