A configuration workaround for Eclipse Auto plug-in dependencies

Eclipse's plug-ins have the following features:

(1) Each plug-in has its own independent ClassLoader

(2) The interaction of plug-in resources is controlled by the attributes of "export-package, Require-bundle, Import-package" in MENIFEST.MF.

(3) The plugin cannot depend on each other

Recently developed systems require permission control, control granularity to view definition, command definition, and so on. When the system is started, you need to load the current user's configuration according to the configuration (database save), so the problem comes:

Eclipse's plug-ins need to be relied upon to reference. For example, B relies on a, B can refer to a, but a does not rely on B,a cannot invoke the resources of B. This means that a class of B cannot be referenced if a is a class that detects and loads the plug-in configuration as a permission. One solution is to add a dependency on B. But when the system becomes larger and cannot be developed by a development team, how does a know what plug-ins are? It is obvious that it cannot be prescient. So there is a problem.

Fortunately, Eclipse provides an extension of the Menifest file, extending the eclipse-buddypolicy instruction.

URL: Http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_ Manifest.html gives an introduction to this directive.

The Eclipse-buddypolicy header is used to specify the buddy classloading policies for a bundle. The Eclipse-buddypolicy header must use the following syntax:

Eclipse-buddypolicy:: = (policy-name) (', ' policy-name ') *
policy-name:: = (' dependent ' | ' Global ' | ' Registered ' | 
                  App ' | ' Ext ' | ' Boot ' | ' Parent ')

Registered-indicates that the buddy mechanism would consult bundlesthat have been to it. Bundle willing to is registered to a particular Bundle add in their manifest: "Eclipse-registerbuddy: <bundlesymbolicna Me> "; Dependent-indicates that the classes/resources would be looked uptransitively the dependent of the bundle; Global-indicates that the classes/resources would be looked up in Theglobal pool of exported package; App-indicates that the application ClassLoader would be consulted; Ext-indicates that the Extensiont ClassLoader would be consulted;   Boot-indicates that the boot ClassLoader'll be consulted. So according to the above description, insert in the A plugin menifest file

Eclipse-buddypolicy:global

directive, then B references A,a does not need to refer to B, but the resource of B that needs to be invoked in a requires export in B. In this way, you can use the resources of B in a.

In this way, the function of the filter interface is realized according to the user's role, and the control of the interface is implemented well.