shivanshukumar / pluginanalyser Goto Github PK

This will allow for a more accurate modeling of the feature model (of features and plugins depedencies).

ManifestParser doe snot account for indirect bundle dependency specification through the 'uses' property in an 'Export-Package' dependency entry.

A Uses property calls for implied imports for the importer who is importing an exported package that use some other package (which my be exported by some other plugin and thus implying a dependency on that as well).

How to treat the 'uses' clause with respect to PluginAnalyser first has to be decided, based on which appropriate changes can be made.

Ref.: OSGi core 5.0.0 specification section 3.7.5 Package Constraints (page46-48)

The fix would include overriding the entire set of classes of apache ivy that are involved with bundle manifest parsing , and modify classes such as ManifestParser, ExportPackage, BundleRequirement and BundleCapability to allow for capturing such details.

The problem goes on to also involve other directives associated with Export-Package such as x-internal, x-friends, includes and excludes (the last two basically overriding the classes exported or not). A fix for these would also be good as it would lead to a more complete and accurate dependency (package based) resolution.

the dependency should ideally be fragment=> bundle bit for now in the dependencies Feature Model, is has been modeled as fragment <=> bundle so as to satisfy the macosx_specifc fragment => eclipse_swt case, where macosx specific part provides functions that satisfy calls to swt ....

this is not the proper way to go about modeling this i.e. fragment => bundle is correct, fragment <=> bundle is not.

.... the places where such a case exists are not critical however bit it would be nice to do this moving forward.

This is to enable garbage collection of unwanted plugin metadata and load as needed.
Thereby overall reducing the required heapspace for JVM.