Gads, just put the implementation in a different package (assuming you can) then you can put it wherever you like with impunity. If you can't, put it all in one bundle.
Jeff On 2010-05-11, at 3:22 AM, Peter Kriens wrote: > 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
