Better ordering for quick fixes

Another reference for implementing relevance for quick fixes is in jdt:

org.eclipse.jdt.internal.codeassist.CompletionEngine.proposeType(..)

It contains additional relevance calculations, although not all may be applicable to Groovy.

Some more things to think about:

1. Prioritize java, javax, groovy, groovyx, and grails imports over others
2. Prioritize source types over binary types
3. Prioritize types that share package prefixes (however the sharing should be more than com.* or org.*).

Initial implementation of Relevance rules for determining Type relevance for add missing import quick fix. This is not the final version, and is only attached for code review and debugging.

Thanks for the patch. Appears to be working so far. I won't close this until I commit.

Attached new implementation with the following changes:

• Different relevance rule implementation, where a rule is mapped to an enum rule type.
• When constructing a RelevanceRules object, if no subset of rule types are specified (i.e., null or empty list of rule types), by default all the available rule types will be used when computing the relevance of a Java type.
• Since the Accessibility rule has not been tested, it has been commented out from the add imports quick fix. The code for accessibility rule is still present in RelevanceRules, except that the subset of rules used by the quick fix excludes the accessibility rule.
• Added missing javadocs and copyrights

Several changes from the last patch:

• New rule: prioritising based on java, groovy, groovyx, javax and other libraries, in that order.
• New rule: importing types from packages with similar package segments have higher priority, therefore importing com.test.TypeA into com.test.test.TypeB has higher priority than importing org.test.TypeA.
• Changed the relevance API to accept a list of context types obtained from the context compilation unit. This allows additional rules that require comparison between the context project and the suggest import type project, as well as the rules mentioned above.
• As some rules may clash with one another, Relevance rules now support Relevance categories, therefore each rule can define a Relevance category. Categories are defined by the existing: org.codehaus.groovy.eclipse.codeassist.proposals.Relevance.
• Added more javadocs, cleaned up code, and fixed some bugs.
• There are now 5 relevance rules: Source/Binary rule, type modifiers rule, type accessibility rule, java/groovy/groovyx/javax ordering rule, and similar package name rule.

Changed relevance categories so that it can be used in content assist. The rule categories still may need to be adjusted, in particular the modifier rule.

Final tested patch. Commented out the Accessibility rule for this version of Groovy Eclipse as it is not fully tested. The remaining 4 rules have been tested. Also added logic to handle cases where imports are being suggested from within the same compilation unit, to make it compatible with content assist.

Thanks for the patch, Nieraj. I have committed it with some changes. I had originally hoped to use your patch largely as-is for type completion proposal ordering, but unfortunately, I had to make some fairly significant changes.

With quickfixes, you have access to the IType that you are proposing, but during content assist, you do not. There is only the fully qualified name, modifiers, and accessibility available. This means that rules like source/binary and same project cannot be calculated during content assist. Also, this means that I had to add a second method to IRelevanceRule that is applicable during content assist.

The result is something that is less clean than your original patch, but it is working in both situations. If you want to clean things up, then feel free to, but I think what we have now is sufficient.

• Minor refactoring in the content assist support in RelevanceRules. For similarly named packages rule, the quick fix version should delegate to the content assist version without having to repeat the rule calculation. The fix simply removes the unnecessary calculation. All test scenarios pass.

Thanks for the patch. It looks reasonable and I have applied it. I will be committing later today.