Question

I’ve been thinking some about ‘good practice’ regarding package structure within osgi bundles. Currently, on average, we have like 8-12 classes per bundle. One of my initiative/proposal has been to have two packages; com.company_name.osgi.services.api (for api-related classes/interfaces (which is exported externally) and one package com.company_name.osgi.services.impl for implementation (not exported)). What are the pros cons of this? Any other suggestions?

Answer 1

You might also consider puting the interfaces in com.company_name.subsystem, and the implementation in com.company_name.subsystem.impl, the OSGI specific code, if there is any, could be in com.company_name.subsystem.osgi. Sometime you might have multiple implementation of the same interfaces. In this case you could consider – com.company_name.subsystem.impl1 and com.company_name.subsystem.impl2, for example:

com.company.scm        // the scm api com.company.scm.git    // its git implementaton com.company.scm.svn    // its subversion implementation com.company.scm.osgi   // the place to put an OSGI Activator 

In this sense package structure could be OSGi agnostic, if you later on move to a different container, you just put an additional

com.company.scm.sca     // or whatever component model you might think of 

Always having api and impl in your package name could be annoying. If in doubt use impl but not api.