2008/6/3 Mirko Jahn <[EMAIL PROTECTED]>: > 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 ;-) >
another consideration is when bundles will also be consumed outside of OSGi - especially when the API is common (like aopalliance) and shared amongst several libraries. in that case you'd want the API in a separate jar, to avoid classloader issues outside of OSGi (or you could just force people to use OSGi ;) so +1 for knowing the pros and cons of each approach Just my 2 cents... > > Cheers, > Mirko > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
