| Excerpt | ||
|---|---|---|
| ||
Status: planning |
proof-of-concept |
Current status
The Sling IDE tooling project has been restructured from an Eclipse-only build with Tycho to a build that holds several subtrees:
- shared ( code that is reusable in multiple environments )
- eclipse ( code that is specific to Eclipse )
- cli ( code that is specific to a CLI-only sync tool )
More details are found in the Sling IDE Tooling README file.
The current tooling has proof-of-concept status. Although it is known to work for basic use cases, it lacks in-depth testing and also is able to work only with in-place sync, and should get at least import and export commands.
Comparison to vlt
Vlt is a CLI-focused tool modeled after SCM clients ( checkin/checkout operations ) and works with only a single format ( the canonical FileVault representation ). The Sling content sync CLI tool works on incremental changes for all change types ( as opposed to vlt sync ) and is able to support other serialization formats ( even though none is present yet ). Additionally, using a common code base in multiple environments allow consistency and has more chances to flesh out bugs.
Proposals (old)
Sling IDE tooling for other IDEs, especially IntelliJ, is often requested ( see also
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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/blob/develop/CONTRIBUTING.md )
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.
...
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.
...