Yes your understanding is exactly right. You can use multiple versions of the same module concurrently.
There is one caveat, which is to do with the interfaces between the modules. You said that A depends on B v1, and C depends on B v2. That's fine unless A and C need to communicate with each other using types from B. For example the interface between A and C contains a method with a parameter type or return type of "ClassFromB" (i.e. a class/interface that is loaded from the B module) then OSGi would prevent this graph of modules being wired together. Hopefully it should be pretty obvious why this limitation exists. A and C require different versions of B and therefore "ClassFromB" may have completely changed between the two versions. Or it may only exist in one version, etc. If OSGi allowed it to happen then the JVM would throw errors such as ClassCastException, NoSuchMethodError, LinkageError or IncompatibleClassChangeError. In OSGi we never want to see errors like that... and so long as the bundles are correctly constructed we never will see them. Regards Neil On Sun, Nov 17, 2013 at 10:42 AM, Tom Eugelink <[email protected]> wrote: > > On 2013-11-17 10:11, Ferry Huberts wrote: > >> we have something in development as a better solution to the Maven >> 'problem', but since none of us use it, it's not really high on our list of >> things to do. help welcome... >> > > > Concerning the Maven problem, still being a OSGi newbie, I'm a bit worried > about that. Yes, I expected OSGi to have a up-and-running repositories. > Maybe these exist and I haven't found them yet, but that is not my worry. > > As I understand OSGi has classloaders in place that cleanly separate > modules. So this means a module A may use both module B 1.0 and module C > 2.0, module C 2.0 in its turn also uses module B, but it already upgraded > to B 2.0. So now you have the situation that within the same context both B > 1.0 and 2.0 are in use. And B 2.0 is not backward compatible to 1.0. OSGi > can handle that. > > I really hope I got that right, because this key to my approach; you write > a module and it can be deployed with the certainly that it will use exactly > the specified dependencies. With Maven this is different; if any of the > transient dependencies upgrade something that is used elsewhere as well, > the highest version is used, even over major release. This puts high > pressure on keeping every release backwards compatible and prevent cleaning > up code. > > I would like my BC's to be able to choose whatever version of library they > need, without the worry that they may conflict. > > Tom > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
