Le 24/11/2010 18:44, sebb a écrit : > 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)
Yes, sorry, the example was not complete. thanks for the clarification Luc > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
