Concerning this... > Huh? If only com.bar is present than these dependencies exist anyway? > > A: > Import-Package: com.foo > > B: > Export-Package: com.foo > Import-Package: com.bar, com.baz > > A will resolve to B. B has dependencies that are required to implement > com.foo. If I take > implementation C: > > C: > Export-Package: com.foo > Import-Package: com.bzz > > I will get different dependencies, but A remains oblivious of all this. Agreed, but the problem David was talking about is a different one (I guess). What if you don't actually need the implementation right away. In a very dynamic and as small as possible environment, you just want to have an API and load the implementation later on an as needed basis. Now, if you always distribute the implementation all the dependencies of the Implementation (and their dependencies and so on) have to be present in the container and need to be resolved. Of course you can just define your implementation optional in this case and the question, if you should depend on the API in a fixed instead of an optional way remains, but I think this was the use case David was talking about. One example I can think of out of the top of my head is logging. You might want to have the API present, but no logging service deployed, because it is some sort of thin (ultra light) client. If the service is there, use it, if not... don't bother. Just for the sack of arguments, you can also provide a /dev/null logger as the default implementation, which wouldn't have any dependencies. I think there is plenty of space to argue here. Ultimately, there is no black or white only different shades of gray ;-)
Just my 2 cents... Cheers, Mirko _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
