Hi there,

I was working on understanding bundle resolution and workspaces in BND and 
enRoute. Here is my simplified set up:


workspace 1 two projects

ProjectA.api

ProjectB.provider (this depends on Bundle1 and Bundle2)


I resolve Project B using central maven repository. And release Both ProjectA 
and ProjectB to "Release"


Workspace 2 one project. This workspace has reference to "Release" directory of 
the workspace 1 hence can see ProjectA and ProjectB. However, this workspace 
does not have the Central repository pointing to Bundle1 and Bundle2 above. 
Project in workspace 2 is called


ProjectC.provider (this depends on ProjectA.api)


Here is my question . When I try to resolve Project C, resolution fails saying

"Project C  cannot be resolved because ProjectB cannot be resolved because it 
needs Bundle1."


Why should I have dependencies of my dependencies in my second workplace? Isn't 
it against resolution process? I mean if you have multiple dependencies then do 
you need to go and find every single one of the transient dependencies in your 
current local repositories. This can be exponentially big. Should not 
resolution find the dependencies even though they are not on your local 
repositories? I know I am going in the territory of MVN but I really thing 
there must be a simpler way. Similar to "provided" in MVN may be? or a global, 
I mean literally global "cnf"?


I also tried to export the dependencies of ProjectB.provider from 
ProjectB.provider to aid the resolution in Workspace2 but this does not seem 
right either in terms of the size of ProjectB or conventions of OSGi. So can 
you please tell me how can one use external bundle and resolve without knowing 
the transient dependencies? IF this cannot be done than how should one proceed 
to organise their workspaces while collaborating with others?


Sorry for the long message but I wanted to be as clear as possible.


Regards

-Daghan
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to