Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Red Hat’s Involvement in Eclipse IDE Development



On Sun, Feb 19, 2023 at 12:10 PM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
Eric, 

Thanks for sharing these updates. We at Salesforce also believe in the importance of the language server approach. We are in the process of migrating a large Java code base to Bazel and identified Java+Bazel tooling as an obstacle. We started with integrating with JDT-LS (https://github.com/salesforce/bazel-eclipse/tree/master/bundles/com.salesforce.b2eclipse.jdt.ls).

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? 

I would like to give broader picture for the sake of having things listed:
* JDT, JDT-LS, Platform and Equinox are different projects thus having different repositories
* JDT-LS depends on bundles from Platform, Equinox and JDT
* Platform and JDT bundles needed are spread around multiple repositories in the projects themself (e.g. jdt.core in jdt.core repo and jdt.core.manipulation in jdt.ui repo)
* Reducing repositories and making it easier for outsiders to join could and most probably should start in projects themself (e.g. https://github.com/eclipse-platform/eclipse.platform.ui.tools/issues/31) before considering any bigger changes. There is a lot that can be achieved.
 

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. 

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/



On Feb 17, 2023, at 22:10, Eric Williams <ericwill@xxxxxxxxxx> wrote:

Hello everyone,

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. 
      • SWT-GTK4 will be important in the not so distant future when GTK3 environments start to disappear in popular Linux distributions.
      • We plan to stop all SWT-GTK work after the 4.27 release.
    • 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.
  • JDT
    • 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.


Sincerely,
Eric Williams

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev


--
Aleksandar Kurtakov
Red Hat Eclipse Team

Back to the top