We support the strategy of building a JDT LS client, potentially replacing the Java editor of JDT UI as it would help reducing duplication between Eclipse and a web IDE (eg., Theia).
Given the new strategy, would it make sense to combine JDT, JDT LS and the new client into a single repository (mono-repo) to allow better refactoring across the stack? One of the problems I face internally is getting new engineers onboarded onto the OSS stack. There are too many interdependent Git repositories, which makes setting up a development environment quite challenging. Lots of time is spend in figuring out workflows and setup issues instead of learning the code base and become productive. It gets especially problematic if we need to submit PRs to multiple repositories, waiting for merges, loosing lot of momentum. Working in a single repo would make things *a lot* easier.
It's ok for the people like myself with lots of Eclipse experience. However, I'm bootstrapping a small IDE team, which is not very experienced in working in OSS, different processes and across multiple Git repositories and "sub" projects.
Any idea how difficult it would be to get JDT + JDT-LS into a single repo first and then look at bringing the prototype
into that repo as well?
A third step would be bringing the Eclipse Resource framework into the same repo as we are also looking at getting more flexible/dynamic project structures but we can leave that discussion for later.
On Feb 17, 2023, at 22:10, Eric Williams <ericwill@xxxxxxxxxx> wrote:
I am the manager of the Eclipse team at Red Hat -- some of you may know me from my days working on SWT-GTK. Red Hat has been one of the major contributors to the Eclipse IDE for the last several years, so we would like to share some changes in our strategy with you.
Our team has been a proponent of LSP based solutions for the last few years, and we intend to focus on this area now more than ever. This will start with concentrating our efforts around the Eclipse JDT.LS project, where we are working on a prototype which makes it possible to use JDT LS in any IDE. We strongly believe that the future of tooling lies in LSP based solutions, and we will therefore be shifting our efforts to focus on this area instead of the “traditional” IDE specific editors.
This change in strategy will affect the development of the Eclipse IDE, and in order to execute on it we will have to change how we prioritize our time spent in various areas:
Simrel: our main deliverable is JDT LS, which will render us disconnected from contributing to the Eclipse SDK. Simrel contribution and many of the surrounding tasks will have to be taken by someone else for the June release.
Eclipse SDK releng work: JDT LS depends on JDT, Equinox and some Platform parts, so we will still be involved in these projects. We will stop work on the following areas:
Releng efforts in service of more than just having a working tarball and p2 site produced.
Daily monitoring of builds.
The simplification and improvement of tests that do not directly end up in JDT LS or affect our daily work.
General Eclipse IDE work: there are some general areas where our efforts will decrease significantly over time.
SWT-GTK development: Currently, the GTK3 port is quite stable. There is also an initial GTK4 port in progress where users are able to run simple SWT applications.
Issues in general: we are still going to be around and will do our best to help with PRs, but fixes are going to come from others more and more often.
JVM, other tools and dependencies version support: only the latest LTS version and later is a priority for us.
We will be reducing our involvement in JDT UI and will refocus our attention on the JDT LS client.
New functionality developed by our team will target core and non-UI parts, such as jdt.core and jdt.core.manipulation. The goal is that they are equally usable for JDT UI and JDT LS. We intend to expose such functionality via JDT LS only, and let other contributors implement it for the JDT UI layer if there is interest.
Other work: the following projects we are involved in will see a few enhancements
Linux Tools (Docker Tooling)
Wild Web Developer (XML, HTML, JS, TS and embeddable and shared Node.js feature)
This list is not exhaustive, and some of the smaller implementation details may change as our work evolves. These overall changes are planned to take effect after the 4.27 release next month. We appreciate your answers and discussions of the above strategy. Every piece of this conversation will help us fine-tune our team’s strategy around Java IDE tooling.
eclipse-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev