[GitHub] [netbeans] mbien commented on pull request #4971: use maven central search service for class name search.

[GitBox <gi...@apache.org>]

mbien commented on PR #4971:
URL: https://github.com/apache/netbeans/pull/4971#issuecomment-1317376099

   > we got informal slack discussion but do you have pointer why/when the removal of classname from central indexer ?
   
   @ebarboni I don't know. However it was a long time ago. I would say its years not months. I actually completely forgot about it and debugged deep into lucene code to figure out why we don't get any results :). Then I remembered reading [this](https://github.com/apache/maven-indexer/blob/6a0c6017794dca6ee1af151f7914ab3cd0e4aa25/indexer-examples/indexer-examples-basic/src/main/java/org/apache/maven/index/examples/BasicUsageExample.java#L274).
   
   
   > Nice! smile I've been wanting to look at using central search service for ages (for NB and a platform app). I assume you've seen the search plugin? https://github.com/emilianbold/maven.search.remote
   
   @neilcsmith-net I remember you mentioning it before but only looked at it now. My first attempt was similar, I did try to implement all queries of `RepositoryIndexQueryProvider` and put it into a module, but it showed that the search service is purely for artifacts and fairly limited. A prefix group ID search wouldn't be easily possible for example. The search is unfortunately not very well documented. I looked through source code to see what it is actually returning.
   
   (btw the search can be also really slow. I sometimes got 10s response time in tests - it does cache though, so repeating the search is faster)
   
   > 
   > Using JDK HTTP is great, but I wonder if requirement for JDK 11 will cause any concern? This module is not excluded from VSCode I think? Perhaps can be in a separate module?
   
   Well yes. This is the remainder of the first attempt to implement it, it was a separate optional module. We can borrow a bit time to use a different jdk 8 compatible client. But keep in mind that maven-indexer and lucene requires now JDK 11 too (maven-indexer has now a [nice multi threaded extraction implementation](https://github.com/apache/maven-indexer/pull/255)). So its not a if, its a when at this point. (we already backported a [whole class](https://github.com/apache/netbeans/blob/4a697ab128d7df8885a8479b5cc4212e6a56835e/java/maven.indexer/src/org/apache/lucene/search/MultiTermQuery.java#L334) due to a bugfix, this already is a fragile hack. If something would load lucene before we do, this will break)
   
   So when will the VSCode extension switch to JDK 11?
   
   > 
   > Could this use pre-existing JSON libs in the IDE (like the plugin does)?
   
   sure. Jackson (or any jaxb json equivalent) is just really convenient in this case and produces maintainable code. Anyone who looks at the POJOs knows what is going on there - if the service changes it can be quickly fixed. Streaming APIs require a few more brain cycles for maintainers :)
   
   This is just an unfinished experiment to start a conversation. The method `find(final List<QueryField> fields, List<RepositoryInfo> repos)` is going to need a special case too if a class name appears.
   
   `NexusRepositoryIndexerImpl` does too much right now IMO. I think we should check if we can split it into indexer and query provider, this might make it easier to work with.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists