As for publishing to maven repo. I believe even though they are published in 
mvn repo we need a local view of it for the resolver to work with. I understand 
you have valid reasons to enforce local index file (np-complete, repeatability 
etc.) but inevitably it requires developers to manually create local view of 
the external repos even before the resolution can work. Are you saying resolver 
can work directly on global mvn repo (without local indexes/views)? If so can 
you explain how?

As for modularity, i cannot see any way out. For example a relatively complex 
application will rely on multiple services, whose implementation bundles will 
require transitive dependencies which in turn might depend on other services. 
Regardless of how specific your service is there will be an external 
dependency. IMHO Even if we assume all the java libraries are designed and 
implemented using osgi practices, transitive dependencies in multiple layers 
can not be avoided. This is exactly what i am facing right now. My services are 
really specific but implementation has external dependencies.

All said, i am not trying to start a philosophical discussion. I just want to 
make my life as easy as possible. In a nutshell, my pain point is local index 
files of external repositories. Can we drop them? If not what is a best way to 
manage them, possibly share an index file or full cnf company wide and use bnd 
to create specific cnf for developer workspace? How does that work for open 
source projects? I am sure you have answers for all these but i am a little at 
a loss now :).


-------- Original Message --------
From: Peter Kriens <>
Sent: Thursday, September 1, 2016 02:42 AM
To: OSGi Developer Mail List <>
Subject: Re: [osgi-dev] Bundle resolution in BND

Your workspaces should publish to a repository (e.g. Nexus) and then consume 
from those repositories. The resolver takes a root bundle (in OSGi enRoute the 
application) and then finds a closure of all bundles from the enlisted 
repositories that have no remaining requirements. So in contrast to maven, all 
bundles are put in a melting pot and then selected from.

If you have systems that have deep transitive dependencies then you’re just not 
working very modular. The core idea of OSGi is to create bundles that implement 
a number of service APIs and use a number of service APIs. So their 
dependencies is solely those service APIs and maybe a few standalone 
implementation libraries. If you see other patterns you either adapt to 
minimize those dependencies or use Maven, a tool that is wonderful with deep, 
very deep, transitive dependencies.

The core idea of OSGi is that the bucket stops at the service boundary.

Kind regards,

Peter Kriens

On 31 aug. 2016, at 13:31, Daghan ACAY 
<<>> wrote:

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
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.

OSGi Developer Mail List<>

OSGi Developer Mail List

Reply via email to