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
