views:

120

answers:

2

If you have a common eclipse/osgi code platform on which you build various products can you/should you inherit activators from the common code

E.g.

org.test.common.PluginActivator
org.test.common.ui.UIPluginActivator

org.test.product1.Product1PluginActivator
org.test.product1.ui.Product1UIPluginActivator

org.test.product2.Product2PluginActivator
org.test.product2.ui.Product2PluginActivator

I want to have all the UI activators inheriting from the common one, and the same for the non-ui activators. The start methods would all be calling super... However I am wondering if this is bad osgi/bundle practice or could cause problems.

Does anyone have any ideas/opinions on this?

+2  A: 

If the child can't run without the parent's bundle anyway (i.e. it has a functional dependency on it), you're not adding any additional coupling by making the Activator inherit from it.

I'd be wary of inheriting from a common parent unless the plugin already had reason to do so as you're forcing the bundle to be loaded even if you're only inheriting some constant.

Rich Seller
If you have checked <b>Activate this plugin when one of its classes is loaded</b> will it be loaded anyway if you haven't inherited and access the constant?
AntóinÓg
It will, but then you would be better to not reference the constant if that is the only relationship between the two
Rich Seller
I guess the use case is more like you have init code in the common bundle that you want to ensure is run, and you call it from the common activator start method, then accessing the bundle (via a constant etc.) to force loading and ensure init code is run.
AntóinÓg
that sounds like a code smell to me. Generally the plugin should be lazily loaded when firt needed, not when your class is loaded.
Rich Seller
A: 

I'm assuming you're doing Eclipse RCP because otherwise I'd recommend Spring DM (or iPOJO, Google Guice with Peaberry, or Declarative Services, ...). That way you'd never need to write another bundle activator again.

On the other hand, my team went with the common abstract BundleActivator for our RCP-related bundles. To me, having the actual bundle activators in a central bundle(s) increases coupling.

hbunny