Sling IDE tooling for other IDEs, especially IntelliJ, is often requested ( see also SLING-5268 - Getting issue details... STATUS ). So far there has been little progress since the build tooling is centered around Maven/Tycho and there is no immediate way of sharing the results. This page lists the possible approaches we can take in making the IDE tooling usable in other IDEs.
Build a single reactor with p2 and non-p2 projects
It may be possible to have a single reactor with p2 and non-p2 projects. Projects such as EGit/JGit have a split build, ( JGit is plain Java, EGit is p2/Tycho ) so we might find some ideas there.
Evaluation
Not possible due to Tycho limitations, see https://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts .
Switch the build to plain Maven
Not everyone builds with Tycho. Bndtools for instance are built with gradle, so no p2 AFAICT. Some resources:
- https://www.eclipsecon.org/europe2017/sites/default/files/slides/Eclipse.RCP_.with_.bndtools.pdf
- https://tomsondev.bestsolution.at/2017/08/28/proper-osgi-access-restriction-warnings-for-efxclipse-maven-projects/
- https://tomsondev.bestsolution.at/2017/08/21/cross-ide-dev-support-for-e4-on-javafx-we-are-almost-there/
- https://tomsondev.bestsolution.at/2017/03/05/e4-on-javafx-with-the-bnd-maven-plugin-with-vs-code/
Evaluation
- bndtools uses Gradle and manually invokes the Eclipse P2 applications to generate the p2 medatadata ( https://github.com/bndtools/bndtools/blob/89f36abd9bbd40557b71045d1c24fbef876cd835/build/build.gradle#L52-L61 ) , which is not suitable for our toolchain.
- e(fx)clipse still uses Tycho ( https://github.com/eclipse/efxclipse-eclipse, https://github.com/eclipse/efxclipse/ )
- EGit and JGit use a three stage build ( https://wiki.eclipse.org/EGit/Contributor_Guide#Maven_Build )
- jgit Maven build
- jgit Tycho build ( uses artifacts from jgit Maven build )
- egit Tycho build ( uses artifacts from jgit Tycho build )
- The Azure Tools for Java build separate IntelliJ and Eclipse plug-ins, with some reuse between them ( https://github.com/Microsoft/azure-tools-for-java/tree/master/PluginsAndFeatures )
Build a Language Server Protocol implementation and reuse it in other IDEs
The Language Server Protocol is an IDE-agnostic way of implementing tooling for programming languages. The content sync part can be thought of as a 'language' itself, while the 'compilation' is publishing on the server.
Having the content sync part implemented as a LSP plug-in would mean much easier re-use in all supported IDEs ( see https://langserver.org/#implementations-client for canonical listing ):
- Eclipse
- Eclipse Che
- IntelliJ ( with plugin )
- Visual Studio Code
- Sublime Text 3
- vim
Notably missing is Netbeans ( NETBEANS-180 - Getting issue details... STATUS ) unfortunately.
Also of interest would be building a LSP plug-in for HTL, which would be much better suited for the task.
Evaluation
I've done a quick spike and implemented a LSP client and server using LSP4J. The implementation was relatively straightforward and allowed me to explore the implications of going the LSP route. Currently LSP is very much geared towards implementing generic editor services, with some additions used for running workspace-wide operations. There is no support for defining IDE models which we can use for the content navigator and the properties views. Therefore the LSP route is not viable for our current needs. Also there is little to be gained by reusing the LSP4J runtime to create a client-server split, since we would have to implement the client part for each IDE.