> 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
