On 24 November 2010 17:01, Luc Maisonobe <luc.maison...@free.fr> 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. At >> >> 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) 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: 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
