Placing API and implementation in two different bundles but in the same package
is an interesting approach to modularity. Though it achieves a certain amount
of independence and substitutability, and thus some kind of modularity, you
will end up fighting OSGi all the way for no obvious gain. There is a very
strong assumption in OSGi that a package is atomic. If you read the Java
Language Specification you will see that packages were intended to be Java's
modules. Modules are by their nature not splittable. In Java it is even worse,
when you're in the same package you have extra privileges, this will allow an
API to see private implementation code and vice versa. Resolving your bundles
would become significantly harder.
To make this scheme work in OSGi you would have to create a facade bundle that
requires your API and implementation, this would just add an unnecessary bundle
to the list. If you have many impls/APIs this adds up quickly.
So, though the idea might seem attractive because you separate API and impl you
will be fighting OSGi all the time. I would advise to keep it simple and spent
your time on something more useful. Just keep API and impl in separate packages.
Kind regards,
Peter Kriens
On 6 mei 2010, at 14:34, Tom Kesling wrote:
> I'm trying to understand the rules/best practices for working with
> split packages.
>
> I have a bundle that depends on a package that exists in two separate bundles.
> The package in one bundle contains interfaces and the package in the
> other bundle contains implementation of those interfaces.
>
> Is this a bad pattern to follow?
> Will this create class loader issues?
> Should split packages be avoided?
>
> Any advice/best practices would be appreciated.
>
> Thanks,
> T
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
