Historically the plugin.xml was the plugin manifest but that changed in Eclipse 3.0 (June 2004) with the adoption of OSGi as the underlying runtime framework and the move to the plugin==bundle mentality. As of 3.1(June 2005), we fully adopted the "manifest.mf defines a plugin" notion. Due to some of that history if you open a plugin.xml or a manifest.mf in the IDE you get the same editor with different tabs along the bottom for the different aspects of a bundle (e.g, dependencies, runtime, overview, extensions, ...). The values you enter there are in fact stored in collection of different files depending on the data. Going forward there is some discussion of adding Declarative Service related tabs to that editor making it a one-stop-shop for things relate to the bundle.
In any event, I don't think there is (should be) much of a shift when moving between Equinox, Felix, ... There certainly will be some differences and where those are annoying/problematic/goofy we are all for working together either in the OSGi context of simply as open source communities to make things better for OSGi adoptors. Please do highlight issues and incompatibilities wherever you see fit (felix-dev, equinox-dev, bugzilla, jira, osgi-dev, ...) Jeff "Rick Litton" <[EMAIL PROTECTED]> 04/19/2006 12:04 PM Please respond to felix-dev@incubator.apache.org To <felix-dev@incubator.apache.org> cc Subject RE: Felix Product Plugin and/or Initial Provisioning Service? Jeff, As I was cleaning up my junk email folder, I was *shocked* to find your email. Somehow, our email server decided to place it here for some reason. And I thought that I was totally being ignored... ;) To respond to your question, I was referring to the use of extension points and plugin.xml file for configuration in addition to the modifications to the bundle manifest file that you mentioned. Don't get me wrong, I do like the concept of extension points. In fact, I implemented this concept (as well as the plugin.xml) where I work. Interestingly, Eclipse calls the plugin.xml as the plug-in's manifest file as opposed to the bundle manifest file that comes with the jar. Hope this helps! --rick -----Original Message----- From: Jeff McAffer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 6:58 PM To: felix-dev@incubator.apache.org Subject: RE: Felix Product Plugin and/or Initial Provisioning Service? "Rick Litton" <[EMAIL PROTECTED]> wrote on 03/14/2006 12:34:05 PM: > Pardon my ignorance on initial provisioning...but are you referring to > the Eclipse Plug-in Architecture? If so, adoption of this architecture > is a major shift in current Oscar or Felix thinking. For one thing, > reconciling the bundle manifest with the Equinox version is a major > undertaking. Regards. As a point of interest, can you clarify how you are differentiating the Eclipse plugin architecture from the OSGi bundle model? Eclipse plugins ARE OSGi bundles and Equinox is a standalone implementation of the OSGi R4 spec. It is true that Eclipse adds a couple of additional headers to the manifest and we have a mess of additional services but for the most part these headers can be (and are) safely ignored when running on non-Equinox frameworks and the additional services, like any service, can be either reused or re-implemented as needed. I don't want to over sell anything here. The reality today is that most Eclipse bundles will not run on other existing OSGi frameworks. This is either because a) other frameworks do not fully support R4 (fragments and require-bundle figure heavily in Eclipse) or b) some of the Eclipse codebase makes implementation assumptions about the framework (Equinox). The former is changing as Felix and Knopflerfish work towards R4 completeness. The latter is still evolving. The Eclipse codebase is large and we are reworking individual bundles as the need/demand arises. In general the Equinox bundles are are clean of Eclipse assumptions. Jeff
