That's interesting. I did track LUCENE-9497 from your comment and gradle/validation/error-prone.gradle
But it seems all the flags are disabled for now. So, is it actually running on pre-commit (check)? Because, for example, we also introduced a custom Doclet to check ? cross-references recently. But error-prone supports JavaDoc analysis as well. So, maybe these things should be consolidated. I am guessing this is a separate discussion from MuseDev's approach as they will primarily run the checks on PRs and show changed warnings only (and with more tools). But it is somewhat connected at the same time in terms of using a static analysis approach. Regards, Alex. P.s. It also means that maybe writing my own error-prone plugin and integrating it into the project is less difficult than I estimated. On Wed, 23 Sep 2020 at 21:04, Mike Drob <md...@apache.org> wrote: > > Note that error prone is part of our standard compilation already. > > On Wed, Sep 23, 2020 at 6:14 PM Alexandre Rafalovitch <arafa...@gmail.com> > wrote: >> >> On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson <to...@muse.dev> wrote: >> >> > On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <arafa...@gmail.com> >> > wrote: >> >> >> I would be super-curious to see how well it would be able to support >> >> >> Solr's gradle build with all the dark magic we seem to have in it. >> >> > >> >> > >> >> > Perhaps I should keep it a secret and ratchet up the suspense, but I'm not >> > much of a showman. >> >> > >> >> > The Infer and FSB tools ran on Solr seemingly fine >> > (https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr&tab=results) >> > but with the noise level you expect on a large project with subtle >> > invariants. The error prone results are lacking so I'll investigate. >> >> > >> >> The results are long enough that they could benefit from faceted >> >> search by source, file, error type, etc. I wish there was an >> >> open-source product you could leverage for such custom structured >> >> search :-) (Yes, I realize your primary interface is PR with much less >> >> noise) >> >> >> >> >> >> >> >> P.p.s. Medium term, I would love to write a custom check that >> >> >> complains about missing @since Javadoc tags for anything that is >> >> >> pluggable/module like, including Analyzers, UpdateRequestProcessors, >> >> >> Stream Components, etc. Knowing when each individual module is >> >> >> introduced is super useful for those on older versions and my previous >> >> >> attempts at fixing this required standalone code that even I cannot >> >> >> get to run again easily now. >> >> > >> >> > >> >> > I know we tweeted about this, but to bring that conversation to the ML: >> > The fastest way to write such a check is probably with an Error Prone >> > plugin. There isn't any support yet for ErrorProne plugins inside of >> > Muse, but this has been on our minds for a while. If someone beats me ot >> > making an error prone pass then I'll gladly make a way to run it. >> >> >> >> I have given error-prone a quick go. It works nicely when I installed >> >> IntelliJ plugin linked from their website. >> >> >> >> But for custom plugin..... Let's just say I got lost between >> >> annotation processing during plugin compilation, annotation processing >> >> including plugin, module/project dependencies and IntelliJ Idea's >> >> options to make it work. So, I could not get a trivial example end to >> >> end in Idea's default project setup. >> >> >> >> But.... they have an example that I could import into IntelliJ idea >> >> and get it to work with Gradle setup: >> >> https://github.com/google/error-prone/tree/master/examples/plugin/gradle >> >> (clone whole repo, point IntelliJ at just that directory as a project, >> >> let it recognize Gradle, etc). >> >> >> >> So, theoretically, if you take that custom plugin and manage to figure >> >> out how to apply it to a custom project, I can keep beating my head on >> >> my own specialized needs in parallel. >> >> >> >> Anyway, the rest of this thread is probably not lucene-dev worthy. At >> >> least not until there is something to show. >> >> >> >> Regards, >> >> Alex. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
