This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Remove backdoor API between ActionProcessor and PathCompletions | ||
|---|---|---|---|
| Product: | apisupport | Reporter: | Jesse Glick <jglick> |
| Component: | Project | Assignee: | Martin Kozeny <mkozeny> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | jtulach |
| Priority: | P4 | ||
| Version: | 7.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 189558 | ||
|
Description
Jesse Glick
2011-05-05 11:18:04 UTC
I don't care if something is nice or horrible. If you want me write a test to make it work, I can do it. Rather than removing the completions I'd like to improve them to offer hint for position and separatorXYZ attributes (as you suggested in an email to dev@platform.netbeans.org today). (In reply to comment #1) > If you want me write a test to make it work What does writing a test have to do with anything? There is an inappropriate dependency which should be cleaned up. Probably P3 is too high, though. > Rather than removing the completions Not sure what you mean; I did not suggest removing anything, just making the impl use the regular editor code completion infrastructure, since the AP cannot offer any useful information. > I'd like to improve them to offer hint for position and separatorXYZ attributes Sure, but that is orthogonal to this issue. Original summary was what I meant. There should be no API to polish. In such case I disagree with the task completely. I wonder how your fingers can type "Better would be to offer no completions"! ActionProcessor should offer no completions; PathCompletions would do so on its own, without going through 269. PathCompletions are not on classpath and they are not called. The suggestion is not valid. (In reply to comment #6) > PathCompletions are not on classpath and they are not called Currently PathCompletions is invoked reflectively from ActionProcessor.getCompletions. The task is to delete ActionProcessor.getCompletions, and rewrite PathCompletions to be a regular provider of editor code completion (not a quasi-implementation of Processor). I still believe that rather than rewriting all our support to editor.completion APIs, we should find a simpler way for regular AnnotationProcessor to get info about structure of layers.
I still consider the task:
> The task is to delete ActionProcessor.getCompletions, and rewrite
> PathCompletions to be a regular provider of editor code completion
invalid.
At most we should have better API than reflection, but removing ActionProcessor is leading us the wrong way.
Whether the solution is to use the regular editor completion APIs or not, it is still a valid request to get rid of the inappropriate API; there are other possibilities. For example, ActionProcessor.getCompletions could check for an optional argument processingEnv.options['layers'] (a space-separated list of URLs), akin to the attribute defined in XMLFileSystem/BinaryFS/WritableXMLFileSystem. If defined, it would use a SAX parser to check for available paths in these layers. apisupport.project could arrange for this processor option to be defined on NBM-like projects, probably by defining an AnnotationProcessingQueryImplementation (which would require a LookupMerger on this SPI if one does not already exist). There is still then an API of sorts to ActionProcessor, but it is going through the proper channel defined by JSR 269 (Processor.getSupportedOptions), and would be amenable to unit testing. |