In that case, you include the API in the client.
In R4 it became a bit more complex because there can now be multiple
class spaces.
In R4, I always added the API to the client.
Kind regards,
Peter Kriens
On 2 jun 2008, at 23:46, Mirko Jahn wrote:
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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
