Re: [equinox-dev] Plugins vs. bundles

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Hey Dorian, 

As you point out, bundles seem to fill two roles, one as a container for a bunch of packages and one as a runtime entity for classloading etc.  This analogous to the plugin/feature relationship but shifted one level of granularity down.  Somewhat (though not completely) independently there are requirements in the OSGi world to talk of dependencies between bundles (rather than just between packages) as in Eclipse.  This led us to add interbundle dependencies to OSGi and enables us to map plugins pretty much one to one onto bundles.  Extensions and extension points are handled separately.

The import/export package semantics in OSGi will impact the way update resolves/validates configuraitons.  We are working on an API that will releive you of understanding/implementing the details of this.  Rather you will be able to model the configuration you are building and interogate it for validation/errors/...  This should be available by M4.  

As you may have noticed, the mechanisms for delivering/managing collections of bundles are not defined in OSGi.  That is there is no feature-like concept.  There has been some discussion of introducing something in that area but so far not much detail.  For the Equinox runtime we continue to read platform.cfg files in the standard locations etc and present a view of the plugin registry.  The expectation is that update/install will work as-is as long as people continue to create feature and include plugin.xml/fragment.xml files in their components.  Since Equinox maps these plugins/fragments directly onto bundles, update/installs current validation/management technology should continue to work.  You should let us know of any areas in which this is not true.

Looking forward we would like to enable people to write pure bundles (i.e., not include plugin.xml files and be able to use Import-Package). While the runtime certainly handles this today, tooling and support like PDE and Update/Install need to become aware of these runtime structures.  As I mentioned above, we are sensitive to this and want to provide as much support as possible.  Your feedback on those proposals is very welcome.

We expect to make available much more information in the coming week so stay tuned.

Jeff

Dorian Birsan/Toronto/IBM@IBMCA Sent by: equinox-dev-admin@xxxxxxxxxxx 10/01/2003 10:09 AM

To:        equinox-dev@xxxxxxxxxxx         cc:                 Subject:        [equinox-dev] Plugins vs. bundles

I've been reading the equinox newsgroup and mailing list archives and found very interesting technical discussions on various issues. In particular, I had some interest in the update manager story for an OSGI based Eclipse, and the mapping between various eclipse concepts (plug-ins, features, etc.) to OSGI concepts (bundles, etc.). 

When I read the specs, I get the feeling that bundles are more of a crossover between plug-ins and features: 
- both bundles and plugins are the basic runtime units in osgi and eclipse, respectively 
- in terms of packaging boundaries and division, a plugin seems to capture the developer's need for function reusability, features being the function delivery mechanism, whereas bundles seem to be more like features in this respect. In other words, plugins seem to be more fine-grained than bundles. 

As such, one item I couldn't find in the archives is how it was decided to pretty much equate an Eclipse plug-in with an OSGI bundle. I see the similarities, but I was wondering whether alternate "mappings" have been discussed and would appreciate any pointers. 

-Dorian