This is certainly an option if you are the author of both the client and
impl but for cases where there is a third party library with an api you
want to use it seems a little odd to include the third party lib in all
the client bundles?
Definitely more than one way to solve this which is great. Also assuming
you use import-package and not require-bundle (shudder at prospect) you
can always refactor your application from a single bundle to multiple
bundles (or in the other direction) when/if you find the problem.
I guess from a distributed point of view I tend to start from one end of
the problem where as embedded development tends to start at the other
end and all depends on which ever model you find easiest to work with.
Regards,
Dave
Peter Kriens wrote:
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
_______________________________________________________________________
This email has been scanned by both Message Labs and Paremus internal
systems for viruses and inappropriate attachments. Email suspected of
carrying a virus payload or inappropriate attachment will not be
delivered to you, and the sender will receive an appropriate warning
notice.
_______________________________________________________________________
_______________________________________________________________________
Paremus Limited. Registered in England
No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or entity to
which it is addressed and may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other than the
intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from any computer.
_______________________________________________________________________
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
