Hmm. I like implementations that carry their interfaces. OSGi can handle
multiple implementations that carry the same API code. Refreshing might
then sometimes restart a bundle that could have been prevented but I
fail
to see that as a big drawback.
I think it is crucial that bundles run out of the box and not require
you to chase other bundles to get it to work. This first level
experience is
quite important. Just doubling the number of bundles because you might
have
to stop a bundle does not like the right trade off to me.
In the OSGi build, all the implementations care the interfaces they
implement
so they always run out of the box so setup is simplified.
I.e., the org.osgi.impl.service.log .jar bundle carries the packages
org.osgi.impl.service.log + org.osgi.service.log. Obviously, bnd makes
it quite simple to construct these type of bundles.
Kind regards,
Peter Kriens
On 2 jun 2008, at 18:11, 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.
Jeff
_______________________________________________
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
