Overall I agree with Neil but have some
nit-like comments that may be relevant...
Neil Bartlett wrote on 03/30/2006 07:50:21 AM:
> "Installed" means that the bundle has been installed into
> but some or all of its dependencies (ie both through Requires-Bundle
> and Import-Package) could not be resolved yet.
> "Resolved" means that the bundle is installed AND all of
> named in Requires-Bundle are installed AND all of the Import-Packages
> have been wired to a corresponding Export-Package in an installed
the prerequisite bundles (either via require or import)
must be *resolved* for the dependent to be resolved.
> "Active" merely means that a Resolved
bundle has an Activator and the
> start() method has been called by the framework. In pure OSGi terms,
Any bundle can be started. Having an Activator
is not a prerequisite.
> bundle is only activated if another bundle asks
the framework to start
> that bundle, for example if the user types "start 10" in
> console. Equinox also has the Eclipse-LazyStart directive which
> indicates that the bundle should be automatically started if any other
> bundle caused a class inside it to be loaded.
Yes, this is included to address scalability issues
both in terms of performance (you dont want to start 1500 bundles at startup)
and usability (figuring out which bundles need to be started in any give
situation is hard)
> Typically a bundle that provides only Java classes (eg the interfaces
> for XML parsing) needs only to be Resolved and never Activated. A
> bundle needs to be Activated only if it registers services, consumes
> services from other bundles, or (in Equinox) registers extensions
> extension points.
Extension/extension point use is completely independent
of startedness. You can remove the Eclipse-LazyStart header and not
start the bundle yet still use extensions. Also, some extensions
do not contribute code so startedness is not relevant.
The key characteristic of needing to be started is
if the bundle needs to proactively register itself in the environment or
allocate resources. For example, a bundle that implements and HTTP
server needs to listen on port 80. It may not have any services,
extensions, ... In the case of services you need an activator only
so that you can get access to the BundleContext. While many bundles
do, there is no requirement that the services you supply be actually registered
in your activator. If we added the previously discussed mechanism
for getting a context without an activator, the need for an activator would
then be a pure lifecycle play.