[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] Red Hat's Future Java Tooling Plans and JDT
|
Hi Eric,
disclaimer: I'm not a jdt committer (just user, some times contributor)
but can understand some of your pain points as I was already hit by them
(e.g. release process) so really would like some improvements in that
area as well!
Just some thoughts here:
1) jdt.core recently enabled github discussions:
https://github.com/eclipse-jdt/eclipse.jdt.core/discussions
it might be good to split your mentioned items into separate discussions
instead of one big "all we need to solve" as its easier to follow more
focused discussion than one big mailing-list thread.
2) If "The Eclipse team at Red Hat" has contributed in the past to JDT I
think its fair to ask for a committer election for some of them so they
get more influence/visibility on the JDT project.
3) If its just a matter of "how can we build / release more
independently" I can offer the JDT-Team to help out at these parts
4) There are already some effort going on to restructure JDT (e.g. the
compiler see https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182 )
but it could need some help from people more familiar with JDT (than me)
to push such initiatives forward, so probably your team can help with
that as well? I think PR backlog is actually something where help is needed.
5) For "users feel lost" I think the best is to just suggest where/what
documentation needs improvements, its often hard to guess *what* holds
users back e.g. the move to github has already lowered the barrier much
I think, but for sure there are things to still improve!
best
Christoph
Am 14.11.22 um 18:21 schrieb Eric Williams:
Hello members of the JDT community:
I am the manager of the Eclipse team at Red Hat -- some of you may know
me from my days working on SWT-GTK. I am writing to you today to give an
update on Red Hat's future plans with respect to Java tooling and JDT.
The age of language support tooling specifically built for one IDE is
long gone. This has made us, the Eclipse team at Red Hat, adjust our
strategy around Java tooling development over time. Years ago, we became
heavily involved in Eclipse JDT.LS, which relies on the Eclipse JDT
project to provide most of the compiler and language functionality
underneath. Our contributions to this piece of the ecosystem have worked
well for years but are no longer sufficient due to considerably reduced
involvement in the JDT project overall.
A significant cause of the decrease in contributions is the lack of
velocity in JDT development, which forces dependent projects, and
potential contributors to stack workarounds in their own projects
instead of contributing the improvements back to JDT. Contributing
JDT.LS specific fixes and improvements upstream to JDT has been part of
our team duties for the last few years. Unfortunately, this is not the
default behavior across the board, which leads us to ask each of you for
some fundamental changes in both JDT and its dependent project’s practices.
Here is a list of things that from our POV are hard requirements for the
projects to continue to thrive:
A) Releng Improvements
- Reorganize the JDT codebase, decouple it from Eclipse specific
concepts (workspaces, resource model, etc.). This is already WIP. [1]
- Move the jdt.core.manipulation project to the eclipse.jdt.core
repository, enabling a separate releng procedure that allows the release
of JDT core bits on demand, easing its consumption by non-Eclipse
projects to consume it.
B) Refactorings
- A big percentage of the Java functionality is tightly coupled with the
Eclipse UI which makes it unusable for JDT.LS (recent thread [2] on the
topic).
- JDT developers should think of core/UI separation from the very
beginning of the implementation of a new feature, instead of
implementing things coupled to UI, and expect to later refactor to JDT
core.
C) Project Rules
Many project rules prevent contributions from people not deeply involved
in development of the Eclipse IDE, while the overall project’s focus
should be adjusting rules towards better community engagement. For
example: “mass changes” and refactorings being accepted only for M1
means that integrators have to wait 2 out of every 3 months for the next
opportunity to have changes merged. Furthermore, the development period
of the Eclipse release cycle falls twice per year during vacation
periods (summer and Christmas), when many committers are not around to
review changes.
D) Code Modernization
In order to attract new contributors, we must make things easier for
newcomers to join. Changes that help newcomers not feel lost in the
codebase, regardless of their immediate technical benefit, must be as
important as changes that technically improve the project.
We (the Eclipse team at Red Hat) would like to ask all of you JDT
committers if we can count on you to work together with us on the above
changes to modernize the project for its continued success. We
appreciate your answers and discussions of the above recommendations.
Every piece of this conversation will help us adjust our team’s strategy
around Java IDE tooling. It will also help guide our decisions about
what projects to invest in, which areas will be a pain-point for our
team, and whether better opportunities should be pursued.
1: https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182
2: https://www.eclipse.org/lists/jdt-dev/msg02169.html
Sincerely,
