To expand on this train of thought as it's getting on towards of end of
day here in the UK so I feel the urge to talk to the wall ;)
The consideration when building bundles is how best to weight the
distribution of code between bundles is which code belongs together from
a client perspective. As with all API decision the designer needs to put
themselves in the clients shoes to decide the correct grouping of classes.
From my view point I try to ensure where ever possible that API bundles
should be dependent only on other API bundles. This limits the possible
spread of the graph beyond the classes need to express the core
semantics of the API.
The pain comes when trying to start client code that depends on an api
and you end up in the cyclical process of resolving the next bundle
required to start.
In newton where we're dealing with remote deployment of bundles this
also has a performance aspect as client code should not depend on
downloading server implementations in order to function.
Possible analogies can be made with physical phenomena such as center of
mass and entanglement. You don't want to have to drag down the weight of
an entire planet just to switch a light switch etc.
So in summary my advice would be to separate impl and api but do so in
such a way as to inherit apis and group related apis for semantic
coherency - simple :)
Regards,
Dave
(shameless link to newton)
http://newton.codecauldron.org
David Savage wrote:
Jeff McAffer wrote:
Leaping on this thread as it's something I've had a lot of experience
unpicking and wouldn't want others to have same pain.
Another issue that is worth considering (and yet another reason to
separate into api and impl) is that due to osgi resolution requirements
if you put your impl in the same bundle as the api this effectively
requires client code to resolve bundles that your impl uses but they
may
have no need of using.
This can rapidly get out of control and in the worst case a client
needs
to import a much larger set of bundles to use a client api than would
otherwise be needed.
Yes, this is definitely a concern. Just to paint the flip side of the
spectrum, if you put the API in a separate bundle then either you have
a lot
of small bundles (high overhead ratio in management and runtime foot
print)
or you lump together unrelated API and have a similar problem to what you
describe.
I'm not countering but rather suggesting that there is not a single, one
size fits all answer.
Agreed on all points.
Regards,
Dave.
Jeff
_______________________________________________
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