Is it reasonable to use different Start Levels to manage the dependencies between OSGi bundles? -

my team trying develop new system based on osgi, , have more 50 bundles , counting. problem is, there dependency between bundles. example, when bundle startup, register service osgi, , when bundle b startup, use service. therefore need bundle startup earlier bundle b. make happen, set start level of bundle less bundle b.

we tried use servicetracker avoid setting start levels, when services count growing up, become difficult manage , understand whole system.

however, found article on internet: osgi , start levels. i'm not sure 2 sentences in it:

• start order within start level indeterminate!
• on whole, when working start levels, never depend on start order. think start levels management issue, not development time issue.

does mean start level not decide start order? when should use it?

is reasonable use different start levels manage dependencies between osgi bundles?

it possible make bundles being dynamic module(use servicetracker track services use), takes more time , demand senior developers, , system become difficult debug.

my answer similar bertrand: should consider using higher-level component-based abstraction solution: scr, ipojo, blueprint, etc.

using start levels control dependencies little using thread priorities in java fix race conditions. sure, might make things work, sort of, while, you'll go insane in process--and you'll lose anyway.

start levels are useful. canonical example if need display splash screen while starting osgi-based gui application putting code in bundle. without start levels there's no way ensure splash screen end displayed when it's supposed be, using start levels becomes trivial.

that said, i've used start levels resolve dependency ordering bugs found in third-party bundles (e.g., spring), though didn't involve service ordering assumptions finding resources (with spring, xsd spring integration custom namespace).