For Red Hat it's important to understand whether the community agrees with us on the overall direction and is ready to accept that a good number of things have to change, not whether change A, B.. X, Y, Z are fine. Thus single discussion
is better suited here compared to going into technical details about possible change X.
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,
>
>
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev