Hi,
There are 2 different architectures for SonarLint flavors: Eclipse and IntelliJ plugins are embedding the sonarlint-core library, while VSCode, Atom and Visual Studio (partially) rely on starting a separate SonarLint process (called server or daemon) and then use inter-process communication between the IDE and the SonarLint process (either the standard
language server protocol, or a custom grpc one).
Since bluej is a Java IDE, I would suggest to use option one, except if there is already a client library for the language server protocol.
SonarLint Core provides an
API to run analysis on file(s) and returns issues. In connected mode, it will also take care of fetching server side data, and storing them in a local storage, but I suggest you forget connected mode for a first implementation. The main work to do is really IDE integration:
- analysis trigger: find a hook in IDE to trigger on the fly analysis (could be on file open/save). You can also have a manual trigger with a menu entry, but that's not the main spirit of SonarLint
- analysis configuration: this is very important for SonarJava analyzer to access the classpath of the file(s) that are analyzed. So you have to extract from the IDE the location of .class and libraries, and populate properties sonar.java.binaries/sonar.java.libraries before calling SonarLint Core
- show issues on the code: again, this is IDE specific code
- optionally show issue list in a dedicated panel
Then there are many other small details:
- redirect SonarLint Core logs to a console (or any other appropriate output)
- have a way to display rule description
- global/per project configuration
All SonarLint flavors are open source, so I suggest you have a look at them, and come back with more specific questions.
Regards,