Why the usage of an extension point implies require-bundle of the provider?

[laeubi]

Currently when one implements a new extension point, PDE always wants to add the provider bundle via require bundle, but it was always unclear to me why exactly this is done:

1. Do we require it to make sure the bundle version of the provider match our implementation?
2. Does Equinox somehow need to for the extension registry to work?
3. Is it maybe only required when using a type from that extension, so an import-package would be suitable as well?
4. ...

[merks]

Notice when you try to add an extension to an extension point in a plugin.xml that it has this checkbox:

In principle there might be extension points where extensions do not in anyway require something of the bundle providing that extension point, but that's no doubt an exception rather than typically. In any case I do expect that anything that causes the bundle to be added to the plugin classpath will be sufficient that the extension points are visible in this dialog. That should be pretty easy to test to help answer this question. I also do expect that it's not necessary for an extension to require anything of the bundle providing the extension point; the extension point processor will find any extension contributing to the extension point from any plugin regardless how how such a bundle is related to any other bundle...

[laeubi]

@merks yes that exactly what I mean (also note there is no "Show only extensions from imported packages, or required capabilities), if you use that checkbox and chosen an extension point then PDE immediately asks you

of course it does not explain the implications what will happen if I chose no...

So I try to find out if there are better ways these days we can guide the user, e.g. one might ask if we not always show all extension points (and make "Show only ..." deselected by default), maybe use required capabilities instead of require bundle and so on.

[merks]

I imagine in the typical case where one will need to implement some interface or extend some class, that the knowledge about which package is involved (needs to be added as an import) is not known. Also keep in mind that most likely most people don't care a hoot about OSGi purity and are perfectly happy with bundle requirements. Seeking to guide people who don't care and don't deeply understand the relatively-complex concepts involved is maybe somewhat futile.

---

Do we have any operation that would let the user easily "convert a bundle require to package imports" instead, of course only importing the packages actually being used?

[merks]

I also think you are taking "required bundles" perhaps a little to "literally"? I interpret the term to mean any plugin that shows in the "Plug-in Dependencies" as displayed in the Explorer, but maybe you interpret it to mean, only bundles that are required by a bundle require but no a plugin that are required by virtue of providing an imported package.

[laeubi]

Do we have any operation that would let the user easily "convert a bundle require to package imports" instead, of course only importing the packages actually being used?

I actually plan to add such cleanup to PDE see for example:

• https://github.com/eclipse-pde/eclipse.pde/issues?q=is%3Aissue%20state%3Aopen%20label%3Aorganize-manifest

but for now I first try to get the existing cleanups working properly :-)