Some more auto-completions

[gunnarmorling]

• In @Mapper#componentModel() there could be shown the list of supported values
• In @Mapper#config() there could be shown a filtered list only containing actual config classes
• In @InheritConfiguration#name()/@InheritInverseConfiguration#name() there could be shown a filtered list of existing method names - handled in Code completion: add completion for InheritConfiguration/InheritInverseConfiguration methods #22
• @Mapper#dependsOn() should suggest only properties of the target bean - handled in Code completion: add proposals for @Mapping#dependsOn #23

[sradi]

I implemented the auto-completion for @Mapper#componentModel() (see https://github.com/sradi/mapstruct-eclipse/tree/issue7_componentModel). The list of supported values is currently hard coded. Other suggestions are welcome.
Before sending a pull request, I'd appreciate feedback on the structural changes, that I made.

[gunnarmorling]

@sradi, sorry for the late reply.

Could you create a pull request also if its in an early stage? Then we have a place where we can discuss it and it isn't at risk of being forgotten ;) You can then still push further commits for incorporating any review comments if needed.

Thanks a lot for your contribution, looking forward to merge your first commit :)

[gunnarmorling]

Btw. @agudian fixed a bug fix for completion of bean properties, so your change probably needs a rebase.

[sradi]

I'd like to start work on auto-completion for @Mapper#config.
@larswetzer, I have a question on how to solve this: Do you think, it's a good idea to use the SearchEngine of JDT to find all classes, that are annotated with @MapperConfig or is there a simpler way to find valid auto-completions for this?

[wetzer]

@sradi, first of all, thanks a lot for your contribution!

I’m not sure whether the JDT search engine performs well in context of content assist, especially if the index is not yet built. But you should give it a try and test the performance.

Another idea would be an iteration over all compilation units of the project and do some AST parsing afterwards.

[agudian]

I've moved out some parts of the todo-list to separate issues.

[gunnarmorling]

Hey @sradi just came across this issue. Would you still be interested in working on this?

[sradi]

Hi @gunnarmorling , I just had a closer look into my work-in-progress from a couple of months ago. My first intent was to finish this issue. But at a second glance, the code completion feature doesn't seem trivial to implement for non-String values (in this case: @Mapper(config=...)).
The current implementation of AbstractAnnotationCompletionProposalComputer.isInRange(...) doesn't work properly, when the compilationUnit is not in a compileable state (compilationUnit.isStructureKnown()==false).
If @larswetzer has any hints, that help me to find an easy solution, I would happily implement it. But I currently don't have the time to get a deeper understanding of JDT.