Community
Participate
Working Groups
Build Identifier: There may be certain quickfixes displayed which we do not care about. These quickfixes are being contributed by PDE. We need some mechanism to filter out certain quickfixes programatically. Reproducible: Always
Can you provide a couple examples? As well, does this go farther than filtering quick fixes? Since a quick fix is generated from a problem marker, does this mean that the problem itself is not valid for your project/context?
(In reply to comment #1) > Can you provide a couple examples? Projects that have the PDE Nature (eg. OSGi bundles), when there is an unresolved import in a Java Class, PDE gives an error of unable to resolve the class, and provides a quickfix to add a Required Bundle to the Manifest. In OSGi Bundles, this is not the best practice, and most Runtimes would not support Require-Bundles in OSGi Bundles Manifest. Instead users should add an Import Package to resolve the error. So a user executes a Quickfix and might get another error saying that the quickfix was not supported. > > As well, does this go farther than filtering quick fixes? Since a quick fix is > generated from a problem marker, does this mean that the problem itself is not > valid for your project/context? The problem itself is valid for the project. The problem is only with the quickfixes offered.
Comment 2 indicates that we should improve what Quick Fixes we offer. However, this bug asks to add filtering support. Do you really need such a filter support or would smarter Quick Fix suggestions on our end be the right approach here?
(In reply to comment #3) > Comment 2 indicates that we should improve what Quick Fixes we offer. However, > this bug asks to add filtering support. Do you really need such a filter > support or would smarter Quick Fix suggestions on our end be the right approach > here? The quick fixes beneficial for Eclipse developers. They are not as useful for OSGi developers using other runtimes. We will need to get a complete list of what quick fixes are problematic. There are two project options that I think would be useful. "Always show extenstions/ext point tabs" and "Show sections specific to Equinox". We can apply these settings to the quickfixes.
Couldn't we detect whether it's an OSGi or Eclipse project by looking at the MANIFEST.MF (e.g. whether Require-Bundle section includes (org.eclipse.core.runtime)?
Zina, Richard, We need a list of the quick fixes that are problematic. From the example provided, the problem is that we provide quick fixes intended for Equinox plug-in developers even if you are working with the equinox related UI turned off. I am renaming this bug to reflect this.
Not necessary for these quickfixes. I would suggest that the quickfixes would have a priority or some kind of weight that determines if they should show up on the top or down the list of quickfixes. implementers of other quickfixes can provide a higher weight to make sure that their quickfixes show up first and it gives the users a guideline that these are the recommended ones in this particular context.
(In reply to comment #7) > Not necessary for these quickfixes. > I would suggest that the quickfixes would have a priority or some kind of > weight that determines if they should show up on the top or down the list of > quickfixes. implementers of other quickfixes can provide a higher weight to > make sure that their quickfixes show up first and it gives the users a > guideline that these are the recommended ones in this particular context. PDE provides both JDT quick fixes in the Java editor and Marker Resolutions in the PDE editors. The quick fixes do provide a relevance (17 for import package proposal, 100 for package export proposal, 16 for require bundle proposal, 0 for search repos for IU proposal). The marker resolutions do not have support for relevance.
> The marker resolutions do not have support for relevance. See bug 232383.
Closing as INVALID. We do not have a list of the problematic quick fixes so we cannot work on a solution. If reprioritizing quickfixes is a satisfactory solution, this is already possible with no changes in PDE.
