Skip to main content


Extensions to Tracing Protocol

The purpose of the Trace Server Protocol (TSP) is to standardize how trace analysis back-ends and trace visualization front-ends communicate. TSP decouples the trace analysis smarts from a given client implementation. It transports trace analysis results of the trace analysis back-end in a standardized way.​

TSP opens doors to new opportunities and possibilities, thereby allowing to:​


  • A standard protocol specifying how trace analysis servers and trace visualization clients communicate​
  • This initiative will hopefully result in some front-end development collaboration and the establishment of a community around TSP


Extensions to LSP and DAP

Developers operate more and more in a multi language/multi stack environment. A way is needed to simplify language support.

In our experience integrating language server protocols (LSP), and emerging debug adapter protocols (DAP) causes a major decrease in IDE maintenance due to offloading of the heavy-lifting to Language Servers. IDEs then are only responsible to present the results of the processing.

LSP and DAP are critical pieces of emerging cloud-based and containerized IDEs such as Theia and Che.

Output: We aim to have an impact in multiple vectors:

  • Eclipse ecosystem: replacing of all web tools through LSP/DAP based web tools
  • VSCode: continue supporting through upstream JDT refactorings
  • Help with Language Servers: extend XML Language Server to support Maven
  • Work with other parties on LSP definition to plug gaps we observe while integrating


Open VSX - Free Marketplace Alternative for vs Code Extensions

Open VSX is a free vendor-neutral extension registry for VS Code extensions.

Why do we want to do this?

VS Code Extensions are currently only published in Microsoft’s Marketplace, which disallows usage from non-Visual Studio products. We want to establish an open alternative, so that VS Code extensions can be consumed by other products as well.

Microsoft’s marketplace is not available as a self-hosted version nor is open-source. We want to allow installations of extension registry within company networks and make that code available under the EPL2.

Output: A registry for VS Code extensions that can be self-hosted as well as an instance of it, publicly hosted by the Eclipse Foundation, which can be used from any non-Visual Studio Products.


IDE Extensions for Serverless and FaaS

Encourage the development and usage of IDE extensions for serverless and FaaS.

Output: New open source project(s) that cover serverless and FaaS development cases.


Standard Developer Workspace Definition

Introduce Standard developer Workspace definition (like a recipe) that will be used by many IDEs and developer tools, and will enable portability and sharing between the different products.

The standard aims to define how all developer tasks (such as: code, compile, build, test, debug, and deploy) can be performed on a single user virtual environment. It may include: IDEs and developer tools, technology stacks, toolchains, security and connectivity instruments, developed source-code and apps (build artifacts) storage.

Note: the focus (and reference implementation) is cloud and Kubernetes

Preliminary Work: Proposal and Guidelines for a Specification, Work in-progress

Output: Standard and Reference Implementation(s)


Back to the top