openide.awt/src/org/netbeans/modules/openide/awt/ActionProcessor.java and apisupport.project/src/org/netbeans/modules/apisupport/project/layers/PathCompletions.java cooperate using a horrible backdoor API based on system properties and reflection, since the AP does not have enough context to offer very useful completions itself - it could only examine the classpath of the module, which will not include other modules expected to be loaded at runtime.
Better would be for ActionProcessor to simply offer no completions, and for PathCompletions to be rewritten to use whatever the appropriate NB API is for supplying code completion in a Java document.
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 firstname.lastname@example.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
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.